Ok, I think we have something that is simple enough to work yet reliable.
Sar will be a jar with META-INF/jboss-service.xml configuration file.
Config file can have classpath elements... these mean make sure the
packages listed are in the (ServiceLibraries) classpath. If you put A.sar
in the classpath of B's jboss-service.xml, only the classes in A.sar will
be added to the classpath: if you want the mbeans too, you have to
independently deploy A.sar. This avoids most of the recursive deployment
headaches you get into if you also interpret A.sar's config file.
Config files can have depends elements (mbean name list) This means wait
to setup the mbeans listed in the config until all the depends mbeans are
deployed.
If you undeploy a package, packages depending on it via classpath or on its
mbeans via depends will be suspended -- have their mbeans removed -- and
when you redeploy the package, the mbeans will come back to life.
You can put a "literal" directory tree in a sar under META-INF/root/ (You
can tell me to put it somewhere else, no big deal), and it will be copied
to (probably) a unique subdir of db (maybe we need a new directory,
"local") and the location bound into jndi under a name specified in the
config file.
In order to be able to wait on RAR deployment, I'm going to make the
RARMetaData a (readonly) mbean -- so also you can read the rar config.
rars and sars will go in ears. Not sure yet about jboss-service.xml
directly in an ear.
There was a bunch of discussion about putting jars in sars, similarly to
jars in rars. Marc kind of vetoed this, but it would be pretty trivial to
put back in.
Finally, following David Maplesden's idea, I'm going to write a deploy
script and make a universal deployer that can read it, and have the
autodeployer simply notice time changes and send packages to the universal
deployer without trying to sort them.
Maybe pellet has different connotations in french...;-)
What do you think?
On 2001.09.23 22:43:38 -0400 Jason Dillon wrote:
> > I don't remember what jason wanted with unix admin pellets, can someone
> > remind me?
>
> I am not really sure what a "unix admin pellet" is... but I probably want
> it anyways... if not just to see what it is.
>
> Sorry, I have not really been following this thread, or really the list
> for
> the past week. If someone could give me a brief breakdown for what is
> being
> diuscused I am suer I could provide you with an oppinon of what an admin
> pellet is and why I/we want to have it. =)
>
> --jason
>
>
> _______________________________________________
> 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
