> > |--including *service.xml files in ears, or sars in ears. One of these
> > is
> > |convenient for making an ear application that contains mbeans, is
> > |deployable as it stands on jboss (the mbean codebase and configuration
> > |being in the included sar), yet can be deployed (as an ear) on other
app
> > |servers. Including ears in sar classpaths doesn't have quite the same
> > |effect, since then the ear would be deployed before the mbeans. I
think
> > it
> > |would be highly desirable to be able to for instance include the
> > |ConnectionFactoryLoader configuration your app needs (to get to its own
> > |personal database) in the ear - the app is then self contained.
> >
> > that's great but we don't have a single real life scenario that warrants
> > this, do we?
>
> Don't lots of people have app-specific mbeans? Don't they want to include
> the configuration for them somehow in the ear? Isn't this what
> application-server specific info in an ear is for?
If you are using app-specific MBeans w/o looking them up through JNDI
you are not J2EE compliant.
> Someone did ask recently for Datasources that were unavailable to other
> apps. If you deploy the ConnectionFactoryLoader mbean for that datasource
> inside the app deployment process, you can put it in the apps private jndi
> namespace so it is unavailable to other apps.
But then the lookup is again not J2EE compliant. And also how does then
the administator administer all these private datasources ?
Andy
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
