February 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: maven-resources-plugin problem

by pgier

"scott.stark(a)jboss.org" wrote : The jboss-common-core 1.0 jar is not a valid release. It was some poc that Ruel did. I reset the common version: | | I removed the dependencies on jboss-logging-spi 1.0 and jboss-logging-log4j 1.0 from the pom. logging-log4j is dependent on commons-core 1.0 which is not valid. I don't think those are needed since jboss-common-1.0.4.GA includes the files from those subprojects, right? A lot of the unit tests are failing, but at least it is building now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023819#4023819 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023819

17 years, 1 month

1
0
0 / 0

[TODO - DEVELOPMENT] - Error starting Jboss

by panr23

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) at java.util.zip.ZipFile.(ZipFile.java:112) at java.util.jar.JarFile.(JarFile.java:127) at java.util.jar.JarFile.(JarFile.java:65) 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

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Automatic Scoped Kernels - A good idea

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : I would like to see the scoped kernel notion overviewed in the context of the existing architecture as it seems its too much of a piecewise prototype at this point. The main sticking points are namespaces, cross kernel dependencies, and relation to type systems/class loaders. | | And AOP Domains (scoped AOP metadata/aspect manager). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023767#4023767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023767

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: WSContractConsumer API in a seam app

by maeste

jboss 4.05 and jbossws from svn trunk. Seam 1.1.6 thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023734#4023734 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023734

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: WSContractConsumer API in a seam app

by jason.greene＠jboss.com

What version of JBossAS and JBossWS are you running on? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023729#4023729 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023729

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by weston.price＠jboss.com

anonymous wrote : | 1) Junk the -ds.xml and move to a -cf.xml which either doesn't support | embedded mbeans or does it via a namespace | Ok, when I proposed this before I believe we had a bit of a disagreement about it and backward compatibility. This actually would be my *ideal* approach. Let's just clean up this shit while we have the opportunity, create a real XSD for our MCF deployments and just make people put MBean defintions where the should be..ie anywhere else but MY stuff! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023710#4023710 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023710

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by weston.price＠jboss.com

Sorry, I posted before reading your latest message about the MBeans. Disregard. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023706#4023706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023706

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by weston.price＠jboss.com

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

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by adrian＠jboss.org

"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"> | |  | <connection-factory>...</connection-factory> | |  | <mbean xmlns="urn:jboss-jmx:5.0">...</mbean> | | </connection-factories> | 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 urn:jboss-jca:5.0:mbean element. 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

17 years, 1 month

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by adrian＠jboss.org

"weston.price(a)jboss.com" wrote : | 1) The element name mappings have to be hardcoded somewhere. Example: | | <min-pool-size/> | <max-pool-size/> | <connection-url/> | <xa-datasource-property/> | | 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; | } | } | | @XmlRoot("local-tx-datasource") | 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

17 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2007