1 Reply Latest reply on Mar 11, 2005 4:03 PM by Tom Elrod

    how best to distribute and workaround jboss-common issue?

    mazz Master

      I'm currently putting together a distribution package for something that uses JBoss/Remoting.

      I have it *almost* to the point where I can ship a .sar for "default" configuration and another .sar for "minimal" configuration (in case you want to deploy in either/or).

      The problem I have is this backward-incompatibility with jboss-common.jar. There is one class (actually, just a method) that JBoss/Remoting needs that is not in any currently released JBossAS (method in PropertyEditors).

      What I currently have now is an ant script that deploys the .sar in the appropriate /deploy directory but it also replaces that class in the JBossAS /lib directory's jboss-common.jar.

      Obviously, this makes distribution slightly more complicated than just shipping a sar and saying "put this in your /deploy directory".

      Due to this, I wanted to be able to ship a .zip file that I can say, "unzip this in your JBossAS home directory and jboss-common.jar will be overlayed in the proper /lib directory and the .sar will be placed in the proper server/default/deploy directory. However, it turns out that the jboss-common.jar that ships with JBoss/Remoting is not compatible with currently shipping JBossAS distros (I have 4.0.1.SP1 that I'm trying this on). So, I really do have to just upgrade this one class in jboss-common.jar and leave everything else that comes with SP1's jboss-common.jar alone.

      Any other ideas to make a distribution easy and work around this problem?

      As a more generic point here - this "patch a class" feature is clearly something we need to consider when we build out JBoss Network - which falls on me and my group :-) Of course, I'm hoping JBoss 5 will help by providing nice patching capabilities down to the class level.