On 2001.12.06 19:03:23 -0500 marc fleury wrote: > he he... > > in fact 2 problems one real one fake > > the fake: 'depends' removal i have been working on my codebase for the > past > 3weeks and the code was update by david j last week :) I was missing it > but > I did update the server deployer hence panic...my bad > > the real: the classpath explicit thingy, I think the davidM idea of > wildcards is important and I really can't fathom why we are tracking > *jars* > ... weird. please explain I might be missing it > the real2: the over the board service.xml I think we got that covered. > > marcf
+ I think I am starting to see more clearly, the mbean-refs in the ServiceController is good, that was added by David J, the ServiceDeployer class dependency "nazi" I am not sure I like :) I think I am there, will fix when I am done cooking/eating putting the little one to bed. marcf I thought * did work for classpath archives, but I never tested it. (Did I take it out? I didnt't think so) I have no problem with having it and making it work. I think the class dependency "nazi" is a good idea, not for initial deployment but for redeployment: if you take a jar away and redeploy it, all the depending packages will undeploy to a suspended state and redeploy when the jar is redeployed. If you have lots (say...50) packages needing the classes from one jar, this will guarantee that they all get stopped and restarted with the new classes. Without this I would always shut down the server to be sure I got all the dependencies updated. This could (I think) be done for mbeans via the MBeanClassLoader. This would be a mbean .. its own class dependency. Since I haven't tried it yet, I don't really know how I'd like it. From just thinking about it, I like the explicitly listed jar dependency better because: first, it provides notes for those who come after you about what they need to get the package to deploy. (MBeanClassLoaders might tell you the jar, but only after they find the class. If they can't find the class because you removed the jar because you thought it was unnecessary, you are stuck). second, you can write down explicit dependencies on things you may need but are not the class of your mbean. So... I'd say lets make the classpath archives="*" work, and use it for the base jboss-service.xml (well, maybe. I'd actually rather be specific about which jars it uses.) Then anyone wanting the jar dependency can use it, anyone not wanting it can leave out the classpath element from their my-service.xml and hope for the best. david jencks > > |-----Original Message----- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of David > |Jencks > |Sent: Thursday, December 06, 2001 6:28 PM > |To: marc fleury > |Cc: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] Depends tag in xml > | > | > |I seem to be getting out of order message delivery today;-) > | > |I wish I knew what problem you were trying to solve, marc. > | > |Somehow I doubt you'll like it marc... however we could reduce the > entire > |dependency mechanism to mbean-mbean dependencies by: > | > | > |Make every package be represented by a DeploymentMBean, as the > |RARDeployment is today. (Andreas's management stuff I think needs to > |represent ejb modules, applications, etc as mbeans, similarly). > | > |In particular, a service.xml file is represented by an mbean: as such, > it > |can have mbean-refs to (mbeans representing) other packages (replacing > the > |classpath element dependency mechanism implemented in ServiceDeployer) > and > |to individual mbeans (bringing back the depends tag functionality) > | > |So, a service.xml file might look like this: > | > |<service security-domain="scottskingdom" virtual-host="???" > |name="MY-APP:name=mbeans> > | > | <!--package dependency, like classpath--> > | <mbean-ref>JBOSS-SYSTEM:service=jbosscx</mbean-ref> > | <!--mbean dependency, like depends tag--> > | <mbean-ref>JCA:service=firebirdsqlDS</mbean-ref> > | > | <mbean class=.... > | > | > |</service> > | > |This could be prettied up with better element names, auto-generated > names > |for package deployment mbeans, etc. > | > |david jencks > | > |On 2001.12.06 16:53:47 -0500 marc fleury wrote: > |> David M and David J > |> > |> still working with the Spaghetti code in ServiceDeployer, I remember > in > |> september we had a "depends" discussion in *MBEAN* dependency, and > DavidM > |> added that to the codebase, I also see a entry in the log from DavidM. > |> > |> now, > |> > |> I can't find anything about the MBean service dependency in the code > |> anymore but this opaque structure of "classweneed and > classesweprovide" > |> and I am veryconfused all of the sudden. > |> > |> question, > |> > |> david m, did you code mbean dependency? was it removed? > |> > |> I am about to blow torch these classes in place andjust want some > |> background information before I apply the torch > |> ---- > |> View: http://jboss.org/forums/thread.jsp?forum=66&thread=5015 > |> > |> _______________________________________________ > |> 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 > > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
