When Jboss is starting the following error is showing:
13:06:35,409 INFO [EARDeployer] Started J2EE application: file:/C:/trabajo/eclipse/workspace/CMS-WEB-STD/domains/jboss-config/CMS/deploy/CMS-ISSUER.ear
13:06:35,471 WARN [JARDeployer] Failed to add deployable jar: file:/C:/trabajo/eclipse/workspace/CMS-WEB-STD/domains/jboss-config/tmp/deploy/tmp52876WS_FTP.LOG
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
Thank in advance
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023801#4023801
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023801
Right, this is definitely a valid approach. It's pretty much the way the MetaData has already been structured. I optimized a bit for datasource deployments, but the structure is essentially the same as what you proposed it just does use JAXB or JBossXB at this point.
The generic *-ds.xml stuff, (MCF crap and whatnot) is the easy part. It's the embedded MBean stuff that I can't quite seem to get my head around in the context of JAXB/JBossXB. My approach up to this point is simply to leverage the ServiceDataParsers to manage this but I am sure there is a better way to do this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023704#4023704
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023704
"adrian(a)jboss.org" wrote :
| It is then simply a case of parsing (using JAXB - or JBossXB with JAXB annotations)
| and extracting the metadata into deployment attachments.
The big problem is the embedded MBeans in the -ds.xml file.
Like Scott said about namespaces, both JAXB and especially JBossXB
(which has even better support) can parse different objects based on the namespace.
But in the current -ds.xml the mbean stuff is not in a different namespace
and the mbean stuff doesn't have a JAXB or JBossXB based parser.
It should be:
| <connection-factorties xmlns="urn:jboss-jca:5.0">
| <!-- Our metadata -->
| <!-- Somebody else's metadata -->
| <mbean xmlns="urn:jboss-jmx:5.0">...</mbean>
This has two solutions:
1) Junk the -ds.xml and move to a -cf.xml which either doesn't support
embedded mbeans or does it via a namespace
2) Include a "copy" of the mbean model in the jca namespace.
When I say "copy", this could just be some form of bridge/wrapper
that updates the real ServiceMetadata objects, it is only there is
to fool the xml parser machinery into thinking there is an
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023702#4023702
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023702
"weston.price(a)jboss.com" wrote :
| 1) The element name mappings have to be hardcoded somewhere. Example:
| All of this stuff has to resolve to something in the MetaData, and then applied correctly to ServiceMetaData instances to construct and deploy the MBeans for a MCF.
Why don't you just write a holder that knows how to create a more structured
metadata object from the flat scheme.
e.g. in JAXB annotations (I'll use fields instead of accessors for brevity)
| public BaseConnectionFactoryDefinition implements PoolMetaData, etc...
| @XmlElement("min-pool-size") public int minPoolSize;
| @XmlElement("max-pool-size") public int maxPoolSize;
| public PoolMetaData getPoolMetaData()
| return this;
| public LocalTxDataSource extendsBaseConnectionFactoryDefinition implements MCFMetaData
| @XmlElement("connection-url") public String connectionURL;
| public LocalDataSourceMetaData getConnectionFactoryMetaData()
| return this;
| public List<ConnectionPropertyMetaData> getConnectionProperties()
| // create connection property metadata
The idea being that PoolMetaData and MCFMetaData (or whatever you call them)
are what the real ds deployer uses when constructing the MBeans/POJOs.
It is then simply a case of parsing (using JAXB - or JBossXB with JAXB annotations)
and extracting the metadata into deployment attachments.
The other big advantage is that somebody can write their own deployer
that creates this metadata some other way and still reuse the JCA real deployer.
NOTE: This is OOP (inheritance) not AOP.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023695#4023695
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023695