If jbossall-client.jar disappears, what jar file will be required for clients? Listing 20-30 jar files in the classpath for a client seems to me to be asking too much work on the part of your customers. In addition, the forums will be flooded with people saying "I am get a class not found exception, which jar file contains class XXX?"
And I am not convinced that a script like jbossws' runclient is the solution either (especially because if often doesn't include all the necessary jar files).
Having a single jar file that includes everything needed for a typical client seems like a good idea to me.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140241#4140241
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140241
Here's a kludgey solution that will work for you:
The only time the TL is used is when, on the remote end, the InactiveRegionAwareRpcDispatcher (IRARD) calls the CacheMarshaller to unmarshall an object. If this object is a method call, it's region is stored in a TL so we know which region to use for the return value.
The return value is marshalled by the RequestCorrelator, by passing in the result of a MethodCall invocation.
Since whenever the IRARD calls into the CacheMarshaller, it is always guaranteed to be a method call, we can change IRARD to call a particular method - say, regionalisedMethodCallFromByteBuffer() instead of the more generic objectFromByteBuffer(), which will return an instance of RegionalisedMethodCall.
| class RegionalisedMethodCall
| MethodCall call;
| Region region;
This way we can get rid of the TL altogether.
The IRARD then extracts the MethodCall, invokes it, and then returns an instance of RegionalisedReturnValue to the RequestCorrelator.
| class RegionalisedReturnValue
| Object returnValue;
| Region region;
The RequestCorrelator maybe (if not ASYNC) then calls CacheMarshaller.objectToByteBuffer() passing in the RegionalisedReturnValue.
And here's the kludgey bit. The CacheMarshaller first inspects the object passed in, and if it is a RegionalisedReturnValue, it only marshalls the return value in it, with the region passed in.
This would prevent any TL leaks if this is not called and won't require any changes in the way JGroups interacts with the marshaller.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140238#4140238
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140238
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | However Maven doesn't use that scheme:
| | http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+...
| | instead it is
| | major.minor.micro-qualifier-build
| | So our
| | jboss-5.0.0.Beta4
| | should be under maven
| | jboss-5.0.0-Beta-4
| | for the version ranges to work properly.
| Can't you hack this?
| e.g. first trying how maven wants it, then also try our own
| So that the old stuff would still work.
I was planning to bring up better support for the OSGi format on the maven dev list. Currently when maven tries to parse the last "." (instead of a "-") of our versions, it decides that we're using a non standard format and gives up on trying to parse it. If it seems worthwhile I can try to change the version number parsing so that it parses everything after the fourth dot as a qualifier or something like that to better handle OSGi.
I don't understand enough about how OSGi works, but as a second option, can we translate the maven version to something OSGi compatible in our builds? So maybe use the maven standard versions in our poms, but then put the equivalent OSGi version string into jar metadata, or somewhere else that it can be used?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140214#4140214
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140214