|
»
« Return to Thread: JavaRpc code modularity
Re: JavaRpc code modularity
by andreas.junghans
::
Rate this Message:
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
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
« Return to Thread: JavaRpc code modularity
| Free embeddable forum powered by Nabble | Forum Help |
