JavaRpc code modularity

[Michael Wyraz]

Hi,

I had a look to JavaRpc because I'd wanted to integrate it into spring.
I have seen that the code is not very modular: the RPC handling code,
servlet specific code and other is all in the RpcServlet. The code
forces the developer that the Service implementation uses the
RemoteService interface and any method declares "throws RemoteException".

Because I need to integrate it in my project structure, I'm going to
cleanup the code a lot. The result will reuse much of the existing code
but will have much cleaner structure. If you're interested, I'll
contribute the result. Who should I do this? Give it a new name and
contribute it as a fork? Send the result to the initial developers?

Regards,
Michael.


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Fabian Jakobs]

Michael Wyraz schrieb:

> Hi,
>
> I had a look to JavaRpc because I'd wanted to integrate it into spring.
> I have seen that the code is not very modular: the RPC handling code,
> servlet specific code and other is all in the RpcServlet. The code
> forces the developer that the Service implementation uses the
> RemoteService interface and any method declares "throws RemoteException".
>
> Because I need to integrate it in my project structure, I'm going to
> cleanup the code a lot. The result will reuse much of the existing code
> but will have much cleaner structure. If you're interested, I'll
> contribute the result. Who should I do this? Give it a new name and
> contribute it as a fork? Send the result to the initial developers?
>  

Hi Michael,

I would suggest you get in contact with the author Andreas Junghans
<andreas.junghans@...> and coordinate your efforts.  I would
prefer  you work inside of the JavaRpc contrib rather than creating a
new contrib with a different name. You could tag the current version
with a version number in SVN so others, who depend on the old API can
still find it and do the changes in the JavaRpc trunk. As a start you
can file this as bug in our bugzilla and attach all patches to this bug.


Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: [phone]
fabian.jakobs@...

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Michael,

Am 19.03.2009 um 08:56 schrieb Michael Wyraz:

> I had a look to JavaRpc because I'd wanted to integrate it into  
> spring.
> I have seen that the code is not very modular: the RPC handling code,
> servlet specific code and other is all in the RpcServlet.

I'm the original author of the RPC code, and I agree that some  
modularity would be very nice. There was a similar discussion back in  
2007:

http://sourceforge.net/mailarchive/forum.php?thread_name=DD15AEA9AC775A43B16E2D31B5FCC7F03E86D1%40exchange.GERMO.DE&forum_name=qooxdoo-devel

One of the proposed refactorings went way too far IMHO, creating 31  
classes/interfaces in total and adding unnecessary external  
dependencies. The code of the other refactoring/rewrite never appeared  
on the list (or in qooxdoo-contrib), so I can't say much about it.

> The code
> forces the developer that the Service implementation uses the
> RemoteService interface and any method declares "throws  
> RemoteException".

This is the simplest way to protect people from accidentally  
"publishing" classes or methods that should not be callable from the  
browser. The way this is handled now, you can simply write some  
services and drop them in the server's classpath - no need to  
configure anything.

By now, I guess JDK 1.4 compatibility isn't important anymore, so a  
better solution would be to use annotations (or maybe some external  
configuration, although I'm not too fond of that - a simple "drop a  
JAR" solution should still exist in any new version).

> Because I need to integrate it in my project structure, I'm going to
> cleanup the code a lot. The result will reuse much of the existing  
> code
> but will have much cleaner structure. If you're interested, I'll
> contribute the result. Who should I do this? Give it a new name and
> contribute it as a fork? Send the result to the initial developers?

I would suggest to make it a new qooxdoo-contrib project. If it works  
out well, we can move the code to the standard RpcJava contrib later  
on (provided it's compatible to the old version).

Regards,

   Andreas


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Michael Wyraz]

Hi Andreas,

my plan is (some parts already done):
- DONE: refactored the org.json.* classes to package
org.qooxdoo.rpc.json because the version used in JavaRpc is not the
original org.json version and may conflict with these (e.g. they do not
know "JsonException")
- DONE: created org.qooxdoo.rpc.AbstractRpcHandler which contains all
JsonRPC specific code from RpcServlet but absolutely no dependencies to
javax.Servlet.*
- TODO: Use commons-logging
- TODO: Update javadoc
- DONE: added support for enums
  - serialization: js object attributes "name"=enum.name(),
"ordinal"=enum.oridinal(), "string",enum.toString()
  - deserialization: Integer -> ordinal, other -> name

I'm also going to create an interface for a service resolver class that
finds a service (by name) plus finds matching methods. One
implementation will behave exactly as yours: get the class from
classpath (acepting only classes that implement RemoreService) and
lookup methods that throws RemoteExceptions. This will ensure 100%
backward compatibility. Another implementation will use annotations. For
this i'm going to use webservice annotations so that such a service can
be used both as (SOAP) webservice plus as Json service.

I'll keep you up to date with my changes.

Regards, Michael.


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Fabian,

mid-air collision of eMails :-)

Am 19.03.2009 um 09:50 schrieb Fabian Jakobs:

> I would suggest you get in contact with the author Andreas Junghans
> <andreas.junghans@...> and coordinate your efforts.  I would
> prefer  you work inside of the JavaRpc contrib rather than creating a
> new contrib with a different name. You could tag the current version
> with a version number in SVN so others, who depend on the old API can
> still find it and do the changes in the JavaRpc trunk.

The reason I suggested a new contrib was to avoid confusion. I think  
many developers are using the qooxdoo trunk (and presumably the  
qooxdoo-contrib trunk), so a refactoring/rewrite is safer in a  
separate code path IMHO (which can also be an SVN branch of course).  
As soon as the changes are somewhat stable, they could be merged back  
to trunk.

But anyway, the most important thing is to get a decently maintained  
Java RPC backend, and if creating a branch or a new qooxdoo-contrib  
project is deemed too complicated, then just go ahead and use the trunk.

Regards,

   Andreas


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Michael,

Am 19.03.2009 um 10:34 schrieb Michael Wyraz:

> my plan is (some parts already done):
> - DONE: refactored the org.json.* classes to package
> org.qooxdoo.rpc.json because the version used in JavaRpc is not the
> original org.json version and may conflict with these (e.g. they do  
> not
> know "JsonException")

Good idea!

> - DONE: created org.qooxdoo.rpc.AbstractRpcHandler which contains all
> JsonRPC specific code from RpcServlet but absolutely no dependencies  
> to
> javax.Servlet.*

Nice!

> - TODO: Use commons-logging

Not so good (IMHO). If at all possible, the "RPC core" should not  
depend on a specific logging framework (or "meta-framework" in case of  
commons-logging). It's always a pain to deal with different logging  
frameworks, even if it just means configuring commons-logging to use  
java.util.logging (assuming you're using j.u.l in your application  
code). Maybe logging can be delegated to sub-classes? This way, you  
could avoid having c-l in your runtime classpath if you don't need it.  
This is no showstopper though - a refactoring that depends on c-l is  
better than no refactoring at all :-)

> - TODO: Update javadoc

Good!

> - DONE: added support for enums
>  - serialization: js object attributes "name"=enum.name(),
> "ordinal"=enum.oridinal(), "string",enum.toString()
>  - deserialization: Integer -> ordinal, other -> name

I'm not so sure about this. enum support is very welcome, but it  
should be possible to do roundtrips (Java => JS => Java). It doesn't  
sound like that's the case with your approach, and it's a bit  
unnatural to deal with an enum value this way in JS. My suggestion  
would be to simply output enum.name() as a string for serialization.

> I'm also going to create an interface for a service resolver class  
> that
> finds a service (by name) plus finds matching methods. One
> implementation will behave exactly as yours: get the class from
> classpath (acepting only classes that implement RemoreService) and
> lookup methods that throws RemoteExceptions. This will ensure 100%
> backward compatibility. Another implementation will use annotations.  
> For
> this i'm going to use webservice annotations so that such a service  
> can
> be used both as (SOAP) webservice plus as Json service.

Sounds good!

Regards,

   Andreas


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Michael Wyraz]

Hi Andreas,

- TODO: Use commons-logging
    

Not so good (IMHO). If at all possible, the "RPC core" should not  
depend on a specific logging framework (or "meta-framework" in case of  
commons-logging). It's always a pain to deal with different logging  
frameworks, even if it just means configuring commons-logging to use  
java.util.logging (assuming you're using j.u.l in your application  
code). Maybe logging can be delegated to sub-classes? This way, you  
could avoid having c-l in your runtime classpath if you don't need it.  
This is no showstopper though - a refactoring that depends on c-l is  
better than no refactoring at all :-)
  

Ok, I'll re-think this ;-) But atm there's dependency to commons-beanutils and commons-collections. So i thought, commons-logging should also be ok. All other approaches would only introduce another (minimal) logger wrapper.

- DONE: added support for enums
 - serialization: js object attributes "name"=enum.name(),
"ordinal"=enum.oridinal(), "string",enum.toString()
 - deserialization: Integer -> ordinal, other -> name
    

I'm not so sure about this. enum support is very welcome, but it  
should be possible to do roundtrips (Java => JS => Java). It doesn't  
sound like that's the case with your approach, and it's a bit  
unnatural to deal with an enum value this way in JS. My suggestion  
would be to simply output enum.name() as a string for serialization.
  

This has pros and cons:
pro: much more simple roundtrips (enum -> string -> enum)
con: loss of information (e.g. i use the "toString()" of an enum to create a readable label for it)

Another solution would be to also accept the { name: ..., ordinal: ..., string:... } object on deserialization (or more generall any object that has an integer property "ordinal" or a string property "name".

Regards,
Michael.



------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Michael,

Am 19.03.2009 um 11:32 schrieb Michael Wyraz:

>>> - TODO: Use commons-logging
>>>
>> Not so good (IMHO). If at all possible, the "RPC core" should not
>> depend on a specific logging framework (or "meta-framework" in case  
>> of
>> commons-logging). It's always a pain to deal with different logging
>> frameworks, even if it just means configuring commons-logging to use
>> java.util.logging (assuming you're using j.u.l in your application
>> code). Maybe logging can be delegated to sub-classes? This way, you
>> could avoid having c-l in your runtime classpath if you don't need  
>> it.
>> This is no showstopper though - a refactoring that depends on c-l is
>> better than no refactoring at all :-)
>>
> Ok, I'll re-think this ;-) But atm there's dependency to commons-
> beanutils and commons-collections. So i thought, commons-logging  
> should also be ok. All other approaches would only introduce another  
> (minimal) logger wrapper.

The other commons dependencies are relatively "harmless" - they don't  
interfere with your application in any way. Logging frameworks OTOH  
can lead to nasty issues with classloading (e.g. leaking class loaders  
when re-loading a web app inside a container), and they require  
additional action on your part if you don't like the default  
configuration. So I'd prefer a minimal wrapper instead of an  
unconditional dependency.

>>> - DONE: added support for enums
>>>  - serialization: js object attributes "name"=enum.name(),
>>> "ordinal"=enum.oridinal(), "string",enum.toString()
>>>  - deserialization: Integer -> ordinal, other -> name
>>>
>> I'm not so sure about this. enum support is very welcome, but it
>> should be possible to do roundtrips (Java => JS => Java). It doesn't
>> sound like that's the case with your approach, and it's a bit
>> unnatural to deal with an enum value this way in JS. My suggestion
>> would be to simply output enum.name() as a string for serialization.
>>
> This has pros and cons:
> pro: much more simple roundtrips (enum -> string -> enum)
> con: loss of information (e.g. i use the "toString()" of an enum to  
> create a readable label for it)

When it comes to presenting a value to a user, you usually need a  
separate conversion anyway (for I18n, formatting, maybe showing icons  
instead of strings, etc). And if you think this through, you'd have to  
add an attribute with the value of toString() to _all_ objects - why  
treat enums in a special way? After all, any object could benefit from  
a readable label, but I don't think that's the right approach (see  
below).

> Another solution would be to also accept the { name: ...,  
> ordinal: ..., string:... } object on deserialization (or more  
> generall any object that has an integer property "ordinal" or a  
> string property "name".

I think this is overkill. After all, an enum is just a way of  
representing a choice out of a certain set. Why send different  
representations of the same information to the client (and back in  
case of roundtrips)? It just blows up the RPC packets.

For special server-side conversions (and I would put a "more readable"  
enum value into that category), I think it would be better to add a  
generic customization facility. For example, you could check if an  
object has a "toJSON" method and use that for serialization instead of  
the default implementation. The same approach has been discussed here  
recently for the client side. Or you could also offer a kind of  
registry where one can register custom serializers for specific  
classes. This would allow you to customize the serialization in cases  
where you can't create a subclass with a toJSON method. What do you  
think?

Regards,

   Andreas


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Michael Wyraz]

Hi Andreas,

I agree with the logging implementation. My new solution is to create an
interface IRpcLogger with isLogEnabled(LogType) and log(LogType, String,
Throwable) where LogType is an enum with all loggable things
(incomingData, outgoingData, parseError, serviceError and a few more).
And a default (Syserr) plus a commons-logging Implementation.

I also agree with your opinion to the enums. I'll serialize it to/from
string. And maybe I'll add custom serializer/deserializer and/or support
for Interfaces like IJSONizable.

For my own app, I'll add a custom interface to my enums (IKeyValue) plus
a custom serializer which does the same like the behavior i have
implemented now.

Regards,
Michael.


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Fabian Jakobs]

Andreas Junghans schrieb:

> Hi Fabian,
>
> mid-air collision of eMails :-)
>
> Am 19.03.2009 um 09:50 schrieb Fabian Jakobs:
>
>  
>> I would suggest you get in contact with the author Andreas Junghans
>> <andreas.junghans@...> and coordinate your efforts.  I would
>> prefer  you work inside of the JavaRpc contrib rather than creating a
>> new contrib with a different name. You could tag the current version
>> with a version number in SVN so others, who depend on the old API can
>> still find it and do the changes in the JavaRpc trunk.
>>    
>
> The reason I suggested a new contrib was to avoid confusion. I think  
> many developers are using the qooxdoo trunk (and presumably the  
> qooxdoo-contrib trunk), so a refactoring/rewrite is safer in a  
> separate code path IMHO (which can also be an SVN branch of course).  
> As soon as the changes are somewhat stable, they could be merged back  
> to trunk.
>
> But anyway, the most important thing is to get a decently maintained  
> Java RPC backend, and if creating a branch or a new qooxdoo-contrib  
> project is deemed too complicated, then just go ahead and use the trunk.
>  

I don't really mind how its managed. For me its important that the
development happens inside of qooxdoo contrib. We have the possibility
to brnach and tag inside of a contrib so this would be my suggestion but
if you feel its better to start with a separate project I'm fine with
it. In the end we should have one "official" supported Java backend and
we have to keep a version which is compatible with the current one.

Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: [phone]
fabian.jakobs@...

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Michael Wyraz]

Hi,

is there a reason that Set is mapped to Object[] with
key=setEntry.toString() and value=true?
I think any collection should mapped to an Array with
value=fromJava(collectionEntry).

Regards, Michael.


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Fabian,

Am 20.03.2009 um 09:21 schrieb Fabian Jakobs:

> I don't really mind how its managed. For me its important that the
> development happens inside of qooxdoo contrib. We have the possibility
> to brnach and tag inside of a contrib so this would be my suggestion  
> but
> if you feel its better to start with a separate project I'm fine with
> it. In the end we should have one "official" supported Java backend  
> and
> we have to keep a version which is compatible with the current one.

Dito.

@Michael, what do you think? Seems like the decision (separate project  
or branch) is up to you :-)

Regards,

   Andreas


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Michael,

Am 20.03.2009 um 09:46 schrieb Michael Wyraz:

> is there a reason that Set is mapped to Object[] with
> key=setEntry.toString() and value=true?

Yes, there's a reason (although it's debatable if it's a good  
one ...). The defining behaviour of a Set (as opposed to a simple  
array) is that the entries are unique. In JavaScript, this behaviour  
can only be guaranteed by working with associative array keys (like in  
the current Java RPC implementation). However, such keys can only be  
strings in JavaScript.

To put it differently: If I wanted the functionality of a Set in  
JavaScript, I'd use an associative array with the set entries as the  
keys. That's the main reason for the current implementation. However,  
I don't think I've ever used Set objects with the RPC, and perhaps the  
current mapping was a bad idea in the first place (especially because  
of the information loss due to the string conversion).

> I think any collection should mapped to an Array with
> value=fromJava(collectionEntry).

That would be consistent, so it's probably a good idea to get rid of  
the special Set handling (which is one more reason to develop the new  
RPC implementation in a separate branch, since it's an incompatibility).

Regards,

   Andreas


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Michael Wyraz]

Hi Andreas,

I'll create a new branch for playing around and getting feedback. If
it's (more or less) stable, we can decide (or not) to replace the trunk
with my version. Ok?

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Michael,

Am 20.03.2009 um 15:07 schrieb Michael Wyraz:

> I'll create a new branch for playing around and getting feedback. If
> it's (more or less) stable, we can decide (or not) to replace the  
> trunk
> with my version. Ok?

Sounds good!

Regards,

   Andreas


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Michael Wyraz]

Hi,

I have created a minimal working implementation:
- RpcHandler which has a method "String handleRequest(String request)"
and does basically the same as the old servlet's doPost method minus all
the servlet stuff
- IRpcLogger (interface) for log abstraction
- IRpcServiceFactory (interface) that a) finds a service implementation
by name and b) finds all possible method candidates for a service name,
method name and args
- IJavaJsonConverter (interface) that converts between java ans json.
Arguments passed for later extensions: the object to convert, the Class
of this object  defined by the method (return type or param type), the
generic Type of the object if pressent and a list of annotations of the
method or parameter.
- IRpcLogger: NullRpcLogger (logs nothing) and ConsoleRpcLogger (to
StdErr or any Printwriter)
- IRpcServiceFactory: AbstractRpcServiceFactory with an abstract
getServiceImplementation(String serviceName) that exports all the
methods of the service class
- IRpcServiceFactory: AbstractJwsRpcServiceFactory with an abstract
getServiceImplementation(String serviceName) that honors
javax.jws.WebService and javax.jws.WebMethod annotations (early test
implementation)
- IJavaJsonConverter: DefaultJavaJsonConverter with similar behaviour as
the old implementation had (most code from there). It has 2 modes for
converting objects to json: normal (converted proprties are read from
the object) and strict (converted properties are read from the class
that the function defines - Example: MyService.getUser() returns an
interface IUser with methods getId() and getName(). The returned
implementations is an object User with an additional getPassword()
method. With useStrinctInterfaceReturnTypes=true, only id and name are
returned by the service. With useStrinctInterfaceReturnTypes=false also
the password attribute is returned.
- A spring handler as frontend (similar to servlet but much more easy to
configure).

I'd need an svn access to commit ;-)

Regards,
Michael.


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Michael Wyraz]

Hi,

I have committed my work at JavaRpc/branches/test. You can check it out
as eclipse project. It contains an ant build script as well.

The project is still incomplete. The servlet is still missing and the
json/java conversions are not finished yet. Also many of the test cases
are still missing (but at least there is a minimal unit test ^^).

Fell free to add more tests there, I'll try to get them working.

My open TODO list:
- servlet
- spring integration (already done but not ready to release)
- more logging
- more documentation
- complete set of tests
- maybe a service factory implementation that is compatible to the
current trunk ("maybe" because it's IMO superseded by the Jws compatible
factory)
- example implementation that does basically the same as the current example

Please give feedback if possible!

Regards,
Michael.


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

Hi Michael,

is the SVN test branch up to date ?
I'm starting to work on the java code base for JavaRPC.

On Mar 24, 2009, at 09:01 , Michael Wyraz wrote:

> Hi,
>
> I have committed my work at JavaRpc/branches/test. You can check it  
> out
> as eclipse project. It contains an ant build script as well.
>
> The project is still incomplete. The servlet is still missing and the
> json/java conversions are not finished yet. Also many of the test  
> cases
> are still missing (but at least there is a minimal unit test ^^).
>
> Fell free to add more tests there, I'll try to get them working.
>
> My open TODO list:
> - servlet
> - spring integration (already done but not ready to release)
> - more logging
> - more documentation
> - complete set of tests
> - maybe a service factory implementation that is compatible to the
> current trunk ("maybe" because it's IMO superseded by the Jws  
> compatible
> factory)
> - example implementation that does basically the same as the current  
> example
>
> Please give feedback if possible!
>
> Regards,
> Michael.
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
> are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly  
> and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
> development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel