« Return to Thread: JavaRpc code modularity
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.- TODO: Use commons-loggingNot 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 :-)
This has pros and cons:- DONE: added support for enums - serialization: js object attributes "name"=enum.name(), "ordinal"=enum.oridinal(), "string",enum.toString() - deserialization: Integer -> ordinal, other -> nameI'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.
« Return to Thread: JavaRpc code modularity
| Free embeddable forum powered by Nabble | Forum Help |