Hi David
My view is that services (in JSR-77 notion: resources) are made available
by the J2EE administartor to the "entire server". It is the responsibility
of
the deployer to ensure that all needed resources are available but it is
not his job to create them because it is the job of the administrator.
When I am not mistaken a DataSource delivers a Connection to a persistent
store. Therefore any application can use it. You shouldn't create one
DataSource for each application, should you ?
But whenever you bundle sevices and application together then one
depends on the other making it difficult for the administrator to manage
the server.
> --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.
What do you gain by deploying the in one step than two except troubles ?
> --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.
I am against this because you make EARs JBoss specific.
The problem here is that you don't know for sure what service you use
because
a J2EE application looks up services by asking a JNDI-Server and by asking
for a JBoss service.
Imaging a DataSourec to a DB with the JNDI-Name is already up and running.
Now you depend on a JBoss service XYZ which uses the same JNDI-Name
(or maybe another). When you rebind then the old service becomes a Zombie
when not then the new service is not running or cannot be looked up.
*serivice.xml deals with JMX MBeans, EJBs etc. deals with JNDI !!
> --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?
See above for the problems. The only thing I can say: KISS
> A lot of this involves putting jboss-specific deployment/configuration
info
> into j2ee files, mostly ears. However, this is specifically allowed for
by
> the spec, and indeed we need a bunch of stuff in ejb jar files. I think
of
> this as extension to include more server configuration that may be needed.
Yes, but the point you are missing is that Service is not what J2EE
application
uses but their registration on a JNDI server.
Andy
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
