On 2001.09.22 14:57:36 -0400 marc fleury wrote:
> |--including non jar packages in the classpaths of a *service.xml sar
> |configuration file. This is free, and very useful for for instance
> making
> |sure a resource adapter is deployed before your ConnectionFactoryLoader
> |mbean that uses it and your xxx mbean that on startup needs the
> |ConnectionFactory.
>
> isn't that already taken care of by dmaplesden mbean dependency?
Well the ConnectionFactoryLoader mbean is but needing a RAR to be deployed
is not -- there is no mbean for a rar.
>
> |--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?
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.
I can't think of a reason to put an ear in the classpath of a sar, and I'm
not about to spend any time working to make it possible - but I'm not going
to spend any time prohibiting it if it comes for free.
>
> |--dependency management: an app might use a mbean from a sar, what
> happens
> |when the sar is undeployed? I'm working (a lot works, but could be
> better)
> |on recursive dependency management, so if you declare (in a *service.xml
> |classpath) in your ear that your app depends on mysar1.sar, myrar2.rar,
> |systemjar3.jar, etc, if one of those is undeployed your app will be
> |undeployed into a suspended state, and redeployed when the package on
> which
> |it depends is redeployed. I don't propose to compute the dependencies
> |automatically, but if you declare them, they will make sure your app is
> |running only when what it says it needs is there. Is this what you are
> |worried about?
>
> Yes that is relevant with Datasources being the simplest example one can
> think of.
>
> not spec compliant though... anything in jsr88?
I can't find any info on jsr88 - do you have a link?
Which areas of the spec is it not compliant with? Is it worse than
optimized local calls? ;-)
david jencks
>
> marcf
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
