|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.
Well his view is ok there.
You are right most resources are used by the whole server, but I can see
services that would only be used by certain applications (just like some
beans are deployed as part of a ear, a web application)
|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 ?
I don't know about datasources. MBeans that are application dependent (as
David is saying) are normal and quite common. Those MBeans can now be
packaged as a SAR and be managed as part of the application deployment,
clear, clean.
|But whenever you bundle sevices and application together then one
|depends on the other making it difficult for the administrator to manage
|the server.
the contrary.
Also remember that what he is proposing still incorporates the current
rabbit hole sar/jsr style of scriplet and package.
In fact when I think about it David's *real* proposal is nothing more than
to add the sar to the ear (and not the other way around david :) and package
MBeans in applications.
It is a *packaging* proposal with deployer logic.
|I am against this because you make EARs JBoss specific.
Yes, but here again the gain is tremendous.
Also the "sar" proposal doesn't really break the standard "ear" it is my SAR
C EAR that does.
But it is what makes sense.
People come to us because we are easy to use, easy to deploy, easy to
administer.
This one is quite clear andreas.
|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.
It's irrelevant to the packaging (Afaik) the naming and how you get a
reference is not overwritten (not like the local naming ref in EARS)
The packaging is an administration nicety, with autodeploy stuff really near
The motto is "clear your own MBeans after you", this would take care of it.
|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 !!
you are quite correct here Andreas and in fact it is the same idea that is
behind the logical names of EJB that are part of a package. The name you
use in code is not the name that is in JNDI...
honestly it is a valid point but making it work cleanly would require the
naming infrastructure to do the indirection (logical) and parse the XML data
to do so.
It is an advanced feature that we can add later.
|See above for the problems. The only thing I can say: KISS
Apply it to yourself as recursive statement.. how pretty.
|Yes, but the point you are missing is that Service is not what J2EE
|application
|uses but their registration on a JNDI server.
the service in app case is real as well.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
