I recently added a small sample explaining how to deal with logins and leaving clients ... Have a look at the sample code in the WIKI ...
Today I found a little bit time to extend the existing wiki.
- I added a detailed howto for using NetBeans 6.9 + Maven2 + SIMON to build a client-server project. There are detailed screenshots and sourcecode samples available. You can even download the complete sample project as a template or starting point for your own development.
- Added a "Hello World" sample for the SIMON 1.1.0 API that makes use of annotations and runtime exceptions
have some fun ...
With SIMON 1.1.0 you can now use any object as a remote object.
Have a look at Simon#markAsRemote() ...
Using this method, you can mark any object as an remote object and pass it to the remote side. There's only one constraint: The object must make use of an interface (at least one). This is due to the fact, that SIMON can only make methods, that are defined through an interface, a remote method. But you do not need the SimonRemote Annotation and you do not need the SimonRemote interface. Great, or?
Later on, I will add another version ob "markAsRemote" that more arguments with which you can define which interface you want to make "remoteable" ...
Next steps are in progress... The former lookup mechnism get's overhauled. If things are done, one can call
to get a lookup object according to his needs. There will be 2 lookup types:
- Name Lookup
- Interface Lookup
The first one is already known. The second one can be used to do lookups by providing the interface name instead of the remote name (useful for spring integration done by Noctarius). Work is still in progress. So don't expect too much from current trunk state in svn.
Yesterday night I had some time to work on SIMON. I tried to add a new feature that improves the simplicity of SIMON.
'Till now, you'd to add "implements SimonRemote" to each and every remote object implemention. SIMON used this as a marker interface to identify which object is a remote object and which not.
That lead to "bad" code design. You had to change your class signature to make the class useable as a remote object.
With the new annotation you simply annotate your remote class with "@Remote". That's all :-)
Further tests have to be made. But it looks already quite good. Next steps are changing the SimonRemoteException to a runtime exception and create a better exception handler/listener-interface for this exceptions. Also the lookup-mechanism will gain some improvements. Right now the base class "Simon" is flooded with different lookup methods. In near future we will have a lookup class where you can use getter+setter to specify your individual lookup. This will make things more clear...
Stay tuned for next updates ...
With each deployment of SIMON to the maven repository, also a project site is generated. The site contains f.i.
- Reports like test coverage
- Dependency Information
Please follow this link:
I worked a bit on the wiki and added the "How to use SSL" manual. Feel free to ask (via forums) if there are problems or if anything is unclear.
Maybe you're interested in discussion SIMONs API and INterface usability:
http://dev.root1.de/boards/8/topics/show/8 (german thread)
If you like to discuss this in english: Just start a discussion about what you think could be improved. I will catch it up and present my ideas.
Until now, I used a two stage version string, like 0.1 or 0.3. As most of maven projects use a three stage version string (f.i. 0.3.0 or 0.0.1). To be more "maven compliant" I changed the version string to 1.0.0-RC1 ... You will wonder "why not 0.3.0???". Well, Simon is growing and growing. With the current development phase, there where a lot of major changes: We moved from plain Java NIO to the MINA framework. Nearly the whole API changed. Many tests have been made, Mantis was frequently used, different applications are running Simon as their network layer. And finally: Simon reached a quite stable stage. To the time is ready to point out: Simon is now prepared for bigger things. So from now on, we will use 1.0.0 and increment.
X = Major version number. This indicates the "generation" of the project
Y = Minor version number. This increments f.i. if an feature is added.
Z = Patch/Bugfix release number.
Each version, which has an identical major/minor version combination is compatioble to each other. For instance:
1.0.5 <-compatible-> 1.0.6
1.0.0 <-compatible-> 1.0.2
1.1.0 <-not-compatible-> 1.0.2
1.5.0 <-not-compatible-> 1.1.6
There are also "sub-versions", like 1.0.0-RC1 or 1.5.0-BETA1 ... These are a kind of "pre releases".
At the moment, there is no open issue for 0.3 stable left.
If there doesn't popup any new issues in the next time, 0.3 stable will be released.
Also available in: Atom