[Design of JBoss Web Services] - jar references from jaxb-impl.jar
by thomas.diesler@jboss.com
David reports:
| 2007-01-09 10:15:29,265 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true
| org.jboss.deployment.DeploymentException: url file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/activation.jar could not be opened, does it exist?
| 2007-01-09 10:15:29,281 DEBUG [org.jboss.deployment.MainDeployer] The manifest entry in file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jaxb-impl.jar references URL file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jsr173_1.0_api.jar which could not be opened, entry ignored rg.jboss.deployment.DeploymentException: url file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jsr173_1.0_api.jar could not be opened, does it exist?
| 2007-01-09 10:15:29,281 DEBUG [org.jboss.deployment.MainDeployer] The manifest entry in file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jaxb-impl.jar references URL file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jaxb1-impl.jar which could not be opened, entry ignored
|
| org.jboss.deployment.DeploymentException: url file:/C:/jboss-4.0.5.GA-ejb3/server/default/deploy/jbossws.sar/jaxb1-impl.jar could not be opened, does it exist?
|
I tracked this down and these jars are referenced in the manifest.mf file within the jaxb-impl.jar file:
| Class-Path: jaxb-api.jar activation.jar jsr173_1.0_api.jar jaxb1-impl.jar
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007811#4007811
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007811
17 years, 5 months
[Design of JCA on JBoss] - Re: XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2
by adrian@jboss.org
I was thinking about this over the weekend.
The best way to fix this would be to implement the XAResource wrapper
that we have been talking about for JCA.
We could then check whether the connection is closed in end()
and also reinstate the old behaviour for a failure (i.e. log a warning).
This would also require some form of xid/transaction mapping
which I'm not sure how we do generically - probably some trick
in the tx.enlistResource() call which will callback on our XAResource wrapper
with the XID?
e.g. Something like:
| public void end(Xid xid, int flags) throws XAException
| {
| // Ignore if we are already destroyed
| if (cl.getState() == ConnectionListener.DESTROYED)
| return;
|
| try
| {
| delegate.end(xid, flags);
| }
| catch (Throwable t)
| {
| // We log the warning and force a rollback
| log.warn("Error ending resource " + cl, t);
| try
| {
| Transaction tx = getTransaction(xid); // ?????
| if (TxUtils.isActive(tx))
| tx.setRollbackOnly();
| }
| catch (Throwable t)
| {
| log.warn("Unable to setRollbackOnly " + xid, t);
| }
| }
| }
|
Similar already destroyed checks would also be possible
in the other calls (e.g. prepare/commit), except there we want to raise an XAException.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007751#4007751
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007751
17 years, 5 months