Hello Marc,
When do you plan to commit all these smart deployer code changes?
Thank you. Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de marc
> fleury
> Envoyé : samedi, 29 décembre 2001 21:17
> À : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] sar problems
>
>
> > 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.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
