Aaron Mulder wrote:
> On Sun, 3 Sep 2000, Rickard [iso-8859-1] �berg wrote:
> > Not necessarily. We could do this for one datasource as well to make it
> > easier to use. But the sad truth is that, yes, these relationships would
> > have to be maintained somehow. Flexible doesn't always mean simple.
> > ...
> > Yes, which is why this is something that we would do once and for all.
> > The server will be pre-loaded with all the right relationships for the
> > default modules. If you want to add stuff, you're on your own. Of
> > course.
>
> Well, I submit that nearly every user is going to set up one or
> more data sources. So there is no "once and for all" for the list of
> MBeans, and we don't want to put every user "on their own". Not very
> friendly.
"Once and for all" for the standard stuff. If people want to replace
things or add things, then its trickier, but mostly a matter of proper
doco IMHO. A GUI tool should be possible. One could also imagine some
kind of tool to "guess" relationships. E.g. "Oh, this service uses this
class, so then its probably a DataSource and I'll add it to the
DataSource aggregate".
> Perhaps this could be avoided if we list each configured MBean
> type (not instance) in our relationships file, and allow for the case that
> an MBean is present on the relationships file but not the real
> configuration file.
Something like the above then.
> So for example, AutoDeployer could list
> DataSourceImpl, JDBCDataSourceLoader, and XADataSourceLoader as
> prerequisites. If any of those were present, they would be loaded before
> AutoDeployer, but if one or more of them were not present, they would
> simply be ignored and the AutoDeployer would be loaded anyway. In any
> case, all beans of the same type would be treated together for
> relationship purposes, so you couldn't distinguish between DataSourceImpl
> A and DataSourceImpl B.
Sure that could be possible.
> As for the service reloading, I'm not sure how you plan to do
> this. Let's say I unload a ClassPathExtension ("CPE"), upon which every
> service depends (since we want the CPEs to be loaded *first*). Now all
> services are unloaded. I change the directory/JAR for the
> ClassPathExtension, and then reload it. Now what gets reloaded? At least
> one of you seemed to consider it simplistic to assume that the contents of
> the conf file were accurate once the server is running (who knows what was
> started or stopped in the mean time?). So what do you reload? Or do you
> have to reload everything manually? You don't want to just reload from
> the file anyway, since it clearly had a bad CPE entry, and if you reread
> the file (loaded everything again) and then unloaded the bad CPE entry
> again it would re-unload all the services. Aargh!
I expect the CPE MBean to be replaced with something else further down
the line. It is a temporary hack in my mind. JMX, the spec, provides for
the kind of updating of services I am pointing to.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
