On 2001.09.22 14:16:25 -0400 marc fleury wrote:
> |a sar file will contain a META-INF/jboss-service.xml file (in its
> current
>
> ok
>
> |format) and any number of other compressed package files (jar, rar, ear
> |etc) in an arbitrary directory structure. When deploying a sar file,
> all
>
> I don't understand the "package files" in "arbitrary directory
> structure".
> Be more explicit give an example layout of the sar file.
Well I would hope people would keep it simple and use
jar1
jar1
rar1
jar3
META-INF/jboss-service.xml
however it's just as easy (Toby already wrote the code, which I stole) get
all the packages no matter where they are in case someone wants some
bizarre organization only they understand.
>
> You seem to describe the sar as an "encompassing" structure for ear, rar,
> jar... closer to the "universal" unit of deployment scott is talking
> about.
> Keep it simple.
I'm trying to.. I think david m wants rar dependencies, I think its a good
idea, others will come later if at all.
>
> Also explain how that includes the "directory" requirement from say
> JBossMQ
> that david was asking for.
I'm not convinced by this one yet as I understood his proposal, so I
haven't started trying to implement it. I don't think the temp deployment
directory should be used for the app to write to-- too much like self
modifying code. Also I think administrators would want to be able to
control space usage - especially if you are storing something like a db
there. How about an mbean that sets up a temporary/permanent directory for
you, and interacts with jboss spine in some way to negotiate about where?
(for instance, now, in the db directory)
>
> |the contained packages will be added to the [appropriate, for right now
> |system as in ServiceLibraries] classpath with one classloader (so you
> can
> |deploy/undeploy the sar as a unit, but not the individual contained
> |packages).
>
> I agree with this scoping of the class loader.
>
> |If there are no objections I will include this in the round of
> |modifications I am working on, that make a local copy of sars before
> |unpacking/making classloaders, and share unpacking code with the
> |RARDeployer. I will also take care of converting the existing sars to
> this
> |format and renaming jsrs to sars.
>
> I appreciate you taking the bull by the horn and nailing it down, let's
> put
> an end (== an implmeentation to this discussion)
>
> I am ok with the name.
>
> |Also, a question about j2ee deployment. (sorry I've only been looking
> at
> |j2ee pfd 3) There are a lot of classpath descriptions in section 8.3.1/2
> |etc. referring to using manifest classpath entries to figure out what to
> |include in the application classpath. However, it seems to me that if
> we
> |simply include _all_ packages found in the ear in the application
> |classpath, we will be satisfying this requirement without having to look
> at
> |these classpath entries. Is there a problem with this approach? Did I
> |miss something?
>
> classpath entries are obscure... if we can provide default behavior that
> is
> intuitive then good.
>
> Go ahead,
> marcf
Thanks
david jencks
>
> |Thanks
> |david jencks
> |
> |_______________________________________________
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
