March 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by jason.greene＠jboss.com

The maven version scheme is ugly, and unlike any convention I have seen. They should support custom versioning schemes, and provide an implementation for the common ones in use. I really am tired of having to change the way we do things just to make a build tool happy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140248#4140248 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140248

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar

by clebert.suconic＠jboss.com

We need an input from Scott or Dimitris on this. (I was going to write this before but I pressed submit by accident) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140245#4140245 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140245

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar

by clebert.suconic＠jboss.com

The problem is maintaining it and repackaging it. There are things we can repackage... Anyway... I don't take that decision... I had a similar request for JbossMessaging on jboss-dev-list, and that started a short discussion about jboss-allclient. I don't know if we should remove it or not.. but it can't be the way it's currently done. For instance, for JbossMessaging jbossall-client is next to useless as it doesn't include trove and some other thirdparty libraries we need. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140243#4140243 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140243

16 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-1170

by bstansberry＠jboss.com

That's pretty much what the AS's HAPartition does. There it's a bit less klugey because there's no general purpose CacheMarshaller equivalent that might get passed something other than an equivalent to your RegionalisedReturnValue. As we were chatting, ensuring that the RPC/state transfer/CacheLoader uses of marshalling invoke different marshaller methods can reduce the klugeyness. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140242#4140242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140242

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar

by PeterJ

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

16 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Tests of JRMPInvoker

by bstansberry＠jboss.com

For AS 4 talking to AS 5, use the UnifiedInvoker. For AS 5 talking to AS 4, keep the JRMP/pooled client classes. That assumes if the AS 4 distributions don't export them in client jars that can be brought into an AS 5 classpath without causing conflicts with other stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140239#4140239 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140239

16 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-1170

by manik.surtani＠jboss.com

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

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar

by clebert.suconic＠jboss.com

jbossall-client.jar is a big mess... We have already agreed sometime ago on the forums it should die. It's just a matter of someone taking the courage and removing it from the build :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140237#4140237 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140237

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Parsing more than one file

by alesj

Merge method has been changed a bit: | /** | * Merge files into one piece of metatdata | * | * @param unit the unit | * @param root possibly null pre-existing root | * @param files matching meta files | * @param missingFiles file names that are missing matching file | * @return merged metadata | * @throws Exception for any error | */ | protected T mergeFiles(VFSDeploymentUnit unit, T root, Set<VirtualFile> files, Set<String> missingFiles) throws Exception | { | return null; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140223#4140223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140223

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by pgier

"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

16 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008