|I got bogged down making the locks pluggable and writting a simple
|pessimistic lock.
the good news is that for 3.0 we can plan on doing "optimistic" locking and
what not.
Doing the pessimistic locking all by ourselves is very brave but sometimes
folks prefer to defer to the db. We are having a good time with N-Locks but
man they are tough...
This is pluggable now with simple pessimistic (ie. like today as default).
(as soon as I finish testing and commiting)
marcf
|
|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
