On 2002.08.29 03:26:16 -0400 Michael Bartmann wrote: > Hi David, > > > Do you have any ideas how we can include these customized configuration > xml > > bits in one file, so you can have both regular mbean config, > > <xa-datasource>, <jms-provider>, etc etc. in one file, with each custom > > element being processed by its own xsl? > > There are some different approaches for "more xsl deployment" which > I can think of right now: > > 1) "one big stylesheet" This is what you did for local-tx-datasource and > xa-datasource, and which I extended to no-tx-datasource. you simply > need more "copy through" rules for the rest of the explicit mbean > configuration. In the end it is a maintenance nightmare. > I don't think that this is what you have in mind. > > 2) "deploy the deployer" as it is good tradition in jboss. this is kind > of what you prepared when you made the suffix "-ds.xml" configurable and > what I used to build my "-jmsp.xml" deployer w/o modifying your > XSLSubDeployer code. > But this doesn't seem to be what you are thinking of, cause it > spoils the idea of having the custom config in one big xml file, as > each one has to be treated by its own deployer. > > 3) "transformer chain": Keep different xsl files and pipe every xml file > through multiple transformers (programatically on the java level). > There is even the possibility to use the "reactor"-pattern (as in > the cocoon framework) where every xml-file decides through which xsl > files it has to go by using xml-processing-instructions. > > 4) "mount the sub-stylesheets" using &include-blabla; entities to > include the different stylesheet in a master-stylesheet. This is a > variant of solution 1, trying to avoid the maintenance nightmare. > One the other side you clearly lose "runtime-plugabillity". > > 5) "dynamic transformer": have a master deployer which keeps a DOM with > all the sub-deployers added to the DOM-tree at runtime and build > a new transformer out of this DOM each time it changes (i.e. when a new > sub deployes stylesheet gets deployed) > This is a combination of 2 and 4 which is even more dynamic cause you > don't need a hardcoded master-xsl-file. But you must take special care > to guarantee that your sub-deployers are mounted before your xml files > gets deployed (which is difficult cause you cannot parse the > <depends> tags in your xml file fully *before* transforming it...) > I really don't like things which only depend on deployment sorting, > unless you qualify them as "kernel setup". > > I favour solution 5 (dynamic transformer via DOM).
I'll have to think about all these some more... > > > > > I don't know if this would help, but in jboss 4 you can generate xmbean > > configuration including the initial attribute values and include it > > "inline" in a *-service.xml file. This lets you deploy POJO as xmbeans > > without needing the standard *MBean interface. > > > > Oops, I dont seem to know what POJO means or xmbeans (as oposed to > mbeans) are. There are some concepts in HEAD and Branch_3_2 I did not > hear about at the Palma training or read about in the commercial doco. > (ProxyFactoryFinderInterceptor and friends) > and I try to catch up at those specific points which bug me. Yes, I do that also:-) POJO == plain old java object, the nice thing about xmbeans is you can mark up your class with xdoclet attributes and copious comments and deploy it as an xmbean, and the comments show up as instructions on the jmx viewer. As with all model mbeans, you don't need to have your class implement an interface (blahblahMBean) or be a dynamic mbean. > > > Would you be interested in working on some xsl for jca 1.5 deployment? > I > > have most of the server side stuff written, (and some of it even > tested) > > but havent' started on deployment yet. I think it can be 99% xsl > based, > > generating these xmbean configurations for the necessary adapter > classes. > > > > Right now I'm really busy on my job, but try to give back to the jboss- > community everything I do in my job which fits into jboss and could be > of use for others (I of course even had to backup this with our CEO). > My limited time sadly limits my contributions to things I really > need at work. But if I would come to the conclusion that I needed that > for my work... The best bet for that that I can think of is if you have a legacy EIS that needs to get jboss to do some work for it in a transaction context from the EIS. A jca 1.5 "outbound from EIS" or "inbound to j2ee" adapter can do this, then you'd just need to be able to deploy it... Thanks david jencks > > > Thanks > > david jencks > > > > Thanks also, *you* did the relevant work, > michael bartmann > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
