On 2001.09.22 13:31:47 -0400 Andreas Schaefer wrote:
> Hi David
>
> I am not quite happy with this because of:
>
> - Whereas JAR, RAR, WAR and EAR files are vendor
> neutral archives is the SAR/JSR not vendor neutral
> (it also has nothing to do with J2EE but with JMX).
>
> - SAR/JSR components (resources) servers more than
> just one application therefore it would become a problem
> if a second application uses the same resource which was
> not deployed with the SAR and the SAR gets undeployed.
>
> IMO these two should not be mixed together because they are
> not of the same kind (from a J2EE/JBoss perspective).
>
> Andy
>
I'm a little unclear about which part you are unhappy with...
--the format change, which has been requested by several people, I want to
make it the only format, this doesn't seem to be what you are worried about
--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.
--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.
--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?
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.
Did I miss your point?
Thanks
david jencks
>
>
> _______________________________________________
> 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
