> I'm trying to convert my postgres-ds-service.xml file > into a sar, so I don't > have to copy the jar and then the service file. I > created a sar file with > my previous service file at > META-INF/jboss-service.xml and the postgres jar > (jdbc7.0-1.2.jar) in the root of the sar. Now when I > copy the jar to the > deploy directory, I get an exception about not being > able to find the > jdbc7.0-1.2.jar file. In my jboss-service.xml file I > have the following > xml: > > <server> > <classpath archives="jdbc7.0-1.2.jar"/> > .... > </server>
<temporary> The jar embedded in sar logic was a bit fucked up, I am about to commit the new stuff, greatly simplified and unified along with the unified classloader, it is so pretty and simple it makes me want to cry, anyway, saying in the version you are using, if you declare a classpath element it has to be outside the SAR, since you want the deployment done together (the classes and then the xml stuff mbean creation) you need to create a real sar, meaning a sar with the classes under / of the sar (unpacked). So think of the jar as the sar and in "jar" you just add the service.xml. In the near future (as soon as I commit) I do add support for anything included (done right, with external deployments) so you can pack your own sar with jars and not have to define anything. I am sorry to say that the explicit classpath dependency was a nightmare in code and usage introduced by David Jencks. I have gutted the code and streamlined the usage. let me know if the above doesn't make sense and be on the lookup for the new code it will support what you described. > Do I need to add something to the archives tag to > tell it to look in the > current sar? Do the above, unpack your jar and repack it as a sar with the service.xml in META-INF. That should do the trick. > I there a way to integrate my sar into an ear? In the code I will commit, you can include anything in anything, although the nested russian doll is a nightmare in packaging and why I am pushing away from it, but in any case I did add support for silliness as the one you describe above, i.e. pack anything in anything and if the sub-russian doll is recognized as a deployable type, it is first deployed as such (ear, sar, jar, war) and that is done recursively, so first all the inside dolls are deployed independently and then the outside doll is deployed, this is the way to define *implicitely*, though packaging, the dependencies of deployment. However *again* the recommend "standardized" way is to package your classes as a sar and be done with the russian doll crazyness. marcf ______________________________________________________________________ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66&thread=6402 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
