On 2002.03.02 18:47:40 -0500 Jason Dillon wrote: > > > > > >In general, that won't help. It happens in this case that jbosscx.sar > >defines an mbean that DefaultDS needs, so deployment would wait, but if > put > >the ConnectionFactoryLoader class somewhere else there'd be no way to > look > >for it using depends. Marc wanted to use the MBeanClassLoader to keep > >track of class dependencies and wait if a class was not found when you > >tried to "install" it. I'm not sure how far he got with this. > > > I thought he had given up on this saying there were too many issues... I > could be wrong. > > >Looking for depends elements before the mbean is available also means > you > >either have to parse the xml twice or parse it into a holding structure > and > >then later transfer it to the mbean itself. I guess the latter might be > >possible using xmbean interceptors, but I'm not convinced it will buy us > >anything. > > > I was looking at this, and had a look at the JAXB and some Castor. > Basically we have all of the information we need from the XML. If the > first step was to take XML and turn it into an object model (which would > do type checking, property resolution amoung other things), then would > not have to parse twice. > > I read some parts of the JAXB user's guide and it looks like it must > have a DTD to generate classes... which means that we probably can not > use it for jboss-service.xml, as the config snippet support won't work. > I have not looked at the details from Castor, but if it will allow us > to map xml with out a schema then it might be the way to go. > > Any ways, that still needs to be sorted out and prototyped before we can > go implementing it anywhere. > > Short-term, parsing twice does not seem too bad here...
maybe to you, it sounds disasterous to me. What is the exact problem you are trying to solve? Please restate it concisely. though as you > said I am not sure how much it will help... though I think it would be > the right thing todo here, do depends before installing. > > I think that we might want to "do away" with the .sar format as we know > it... we can figure out how to deal with native libraries and canned > file systems later. Why? And what do you mean "as we know it? What do you want instead, exactly? What capabilities will it have? > > To get around the problem that I am seeing, we would need to pull out > the common resource classes and deploy them from lib/* and then just > deploy the config for the connection*. That would be fine with me. I don't think marc has given up on having some kind of "wait for my class" dependency checking, I think it was the particular multi-threaded implementation with blocking that he gave up on. I'd do almost anything to avoid adding another layer of useless objects in the setup and configuration of mbeans (or any other objects) > > --jason I strongly object to parsing xml into metadata objects and then transferring the metadata to the real objects in another step. IMNSHO this is ridiculous as a model. I support parsing the xml directly into the configuration of the actual objects that you will use to do the work. This is what the current ServiceConfigurator does for mbeans. IMO we can use JAXB or Castor or ?? to do the same with ejb configuration, thus completely eliminating the metadata classes. BTW both JAXB and castor require some form of annotated schema, be it dtd or xsd. david jencks _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
