I will be doing this tomorrow,
I got bogged down making the locks pluggable and writting a simple
pessimistic lock.
I will read this soon, promise
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Jencks
|Sent: Thursday, August 02, 2001 9:19 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Service Archives and ears (was Rabbit Hole
|Commits in 3.0)
|
|
|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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
