Hi Andy,
Let me be more complete: (and I'm not sure how this relates to what Marc is
doing)
So far I submitted a patch that turns ConfigurationService into a Deployer,
so you can add bits of configuration later by deploying mini-.jcml files.
I made it so if you included a (specially named) ServiceControl mbean, you
could control these mbeans as a unit, including undeploying them.
By adding the appropriate line to the autodeployer mbean, these can be
autodeployed. (put your jcml file in deploy, and whee, it gets deployed.
I see ~2 ways of extending this:
1. Add the class files to the jcml file, put it all in a jar. Deployment
consists of adding the classes to the appropriate classpath and then
running the jcml file through the ConfigurationService deployer. I haven't
tried this because I am not an mbean classloading expert and I think it
requires exactly the same classloading extensions as I understand Marc is
working on for web-deploy of jboss.
2. Make it so an application in an ear can include its own mbeans with
their configuration. Again, there are two cases: the classes for all the
mbeans are already on the classpath (such as if you are just configuring a
ConnectionFactory or DataSource to connect to a specific database), or the
case where some of the mbeans have classes not in the preexisting
classpath.
(2) is what I was discussing below. I agree, (1) is also necessary.
A couple of other points:
-- For an mbean specified in an ear, it may be appropriate to create an
"mbean application namespace" by adding an "application=<app-name>" key to
the ObjectName. While this doesn't make the mbeans from one app invisible
to others, it at least makes them distinguishable and avoids possible name
conflicts.
-- I'm not really sure if the ConfigurationService and ServiceControl need
to be separate classes.
-- What do others think of my idea of using a ServiceControl
instance/configuration chunk to make undeploying the chunk of configuration
easier? I required an explicit ServiceControl mbean to be listed in the
.jcml file on the theory that someone might want to implement a different
ServiceControl. This system would be more robust if we just named the
chunk and created a ServiceControl mbean with that name to control the
chunk.
More comments below:
On 2001.08.02 17:33:48 -0400 "Schaefer, Andreas" wrote:
> Hi
>
> > -----Original Message-----
> > From: David Jencks [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 02, 2001 12:26 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] Rabbit Hole Commits in 3.0
> >
> >
> > So how about including in the ear:
> >
> > 1. jboss-ear.xml with dtd like
>
> That's OK for me BUT what do you think about making a different
> Archive Type file out of it like a JBR-file (JBoss service aRchive)
> containing this informations which would allow us to deploy
> services w/o an EAR file. Therefore the "ServiceController" would
> become the JBR-deployer.
I definitely agree, see above.
>
> > <!ELEMENT jboss-ear-conf (module+)>
> >
> > <!ELEMENT module (service-set?, alt-dd?)>
> >
> > <!ELEMENT service-set (#PCDATA)> -- URI of service archive.
> > If you just
> > want some mbean instances and the code is already loaded, just use the
> > alt-dd element.
>
> Because the name of the MBean must be unique the system can figure
> it on themself if the MBean must created and then also if the
> class must be loaded beforehand.
To eliminate possible interference between applications, as noted above we
could add the app-name as a key to the object name. What I'm suggesting
here, aside from being similar to the dtd for ears, is that if you just
want "standard" mbeans like ConnectionFactoryLoaders, you just need the
jcml/xml file: if you have weirdo custom mbeans with your own code, you can
include a JBR/.sar service archive with the classes and the configuration,
or for completeness, both.
>
> > <!ELEMENT alt-dd (#PCDATA)) -- URI of services.xml for mbeans
> > that need
> > configuration, but classes already in classpath
>
> I don't think this is necessary because the deployement should work
> even this instance and/or class is loaded. The only question is how
> to deal with reloading of the class when it is already loaded but
> you changed the MBean or one of the used classes.
This is for, eg., your app connects to a different database than all the
other apps, so you put a little jcml file in with the
ConectionFactoryLoader mbean configuration saying this is a firebird
database with file at this URL and here are the pool parameters I want, and
my app is looking for it with this jndi name. Then the ear includes much
more or hopefully all of the app-specific configuration info it needs.
>
> > We have the opportunity for
> > <!ATTLIST module idref IDREF #IMPLIED> This could attach an
> > mbean set to a
> > specific application component, although I haven't thought of
> > a good use
> > for it. I don't know if this actually makes any sense.
> > Possibly if the
> > ideref is missing the mbean bytecode gets loaded by a global
> > classloader
> > and are available to any app whereas if it is present they
> > get loaded by
> > the application classloader? I don't know enough about mbeam
> > classloading
> > to know if this makes sense.
>
> Normally it uses the classloader of the MBeanServer but you can
> specify a particular classloader to use (either the class or
> a MBean implementing a classloader).
Aha! So we could use this to make the class loaded specific to this
application? So other apps loading different classes with the same name
won't conflict?
>
> > 2. Service archive as a jar-ed file with the code for mbeans
> > together with
> > a jcml-format configuration file.
> >
This is (1) in this more recent post, when not included in an ear.
> >
> > In both layers the .xml file goes in the META-INF directory.
>
> Looking good for me - Mad Andy
Thanks!
David Jencks
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
