I guess I have no particular problem having the ability to put a jboss-service.xml file in a rar, as long as we keep the ability to configure ConnectionFactoryLoader mbeans in any *-service.xml file.
The case with external configuration is crucial for jdbc databases and the required DefaultDS, and could be pretty useful if someone uses the same rar in many applications. On 2001.11.03 03:46:09 -0500 Scott M Stark wrote: > > What is the point of the ConnectionFactoryLoader as an entity > that is coupled to the RARDeployer? None coupled to the RARDeployer, but coupled to the rar itself, it gives you the ability to easily add/remove more connection factories at any time after the rar is deployed, without duplicating the rar classes or disturbing allready functioning ConnectionFactories. I don't see the point of having > trivial deployement of the RAR classes independent of the resource > adapator configuration. For a standalone resource adaptor it is not > so combersome to create a RAR and then configure an mbean, but > for a RAR deployed as part of an ear this does not make sense to me. > I think it would be more straightforward to configure the RAR deployment > using a jboss-ra.xml descriptor as part of the RAR just as any other > deployment unit is handled. Did someone add the "rar in ear" already? In this case, you can configure the CFL in a jboss-service.xml in the ear. BTW, what do you think of putting rar's deployed in ears on the application classloader rather than the system classloader? Thus allowing several apps to have incompatible versions of the same rar. Also btw, the change in 2.4 to put the rar's into the mlet classloader made them non-redeployable I believe. However this is better than inaccessible. david jencks > > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, November 02, 2001 8:08 PM > Subject: Re: [JBoss-dev] JBossMQ JDBC PersistenceManager > > > > Well, don't confuse the rar and the connectionfactory. > > > > What I have on my machine, using the mbean references, is like this: > > > > a rar gets a RARDeployment mbean, which among other things lets you see > the > > default properties and classes easily, but mostly allows you to depend > on > > it. > > > > The ConnectionFactoryLoader has mbean references (dependencies) to the > > required RAR(Deployment) and the ConnectionManager(Factory) it uses. > So, > it > > will deploy as soon as the exact things it needs are present. No need > for > > the artificial reference to RARDeployer. > > > > Do you think we should follow weblogic's lead and allow and encourage > > including a jboss-service.xml in a rar to allow configuring > > ConnectionFactory(Loaders) within the rar? It's certainly easy enough, > but > > I have my doubts about the wisdom. I definitely want to preserve the > > ability to have ConnectionFactoryLoader configurations outside the rar. > > > > david jencks > > > > On 2001.11.02 20:45:09 -0500 Scott M Stark wrote: > > > I'm not particularly keen on how we couple the deployment properties > of > a > > > RAR to an MBean configuration AND a JMX notification. This makes the > > > configuration for a RAR inconsistent with any other J2EE component > > > deployment where this information is specified via a JBoss specific > > > descriptor > > > to build a self contained deployment unit. The configuration is also > more > > > convoluted as you have to specifiy the name of the RAR deployer MBean > > > so that notifications are received. This really makes no sense to > someone > > > who just happens to have a RAR to deploy and hasn't been dragged > through > > > the JMX bus school of religion. > > > > > > I definitely want to change this for 3.0 and so I'll pickup what you > have > > > and > > > finish the deployment layer for 3.0 in a couple of weeks when I > finish > > > the > > > book. > > > > > > I'm not sure if I want to introduce such a change for the handling of > > > RARs > > > into the 2.4 branch. > > > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > > Scott Stark > > > Chief Technology Officer > > > JBoss Group, LLC > > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > _______________________________________________ > 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
