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 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. > 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... > 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
