[JBoss JIRA] (JBESB-3940) JmsConnectionPool reverts to non-xa when transaction has expired
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3940?page=com.atlassian.jira.plugin... ]
Tom Cunningham resolved JBESB-3940.
-----------------------------------
Resolution: Duplicate Issue
> JmsConnectionPool reverts to non-xa when transaction has expired
> ----------------------------------------------------------------
>
> Key: JBESB-3940
> URL: https://issues.jboss.org/browse/JBESB-3940
> Project: JBoss ESB
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transports
> Affects Versions: 4.10 CP1
> Reporter: Kevin Conner
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> The JmsConnectionPool test for whether to create a non-XA session or XA session does not take into account an expired transaction. The test checks for active transactions and, it not found, falls back to the non-XA API.
> The test should only check for an existing transaction, whether active or not, and allow the TransactionManager to fail when invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBESB-3940) JmsConnectionPool reverts to non-xa when transaction has expired
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3940:
-------------------------------------
Summary: JmsConnectionPool reverts to non-xa when transaction has expired
Key: JBESB-3940
URL: https://issues.jboss.org/browse/JBESB-3940
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.10 CP1
Reporter: Kevin Conner
Assignee: Tom Cunningham
Fix For: 4.11 CP3
The JmsConnectionPool test for whether to create a non-XA session or XA session does not take into account an expired transaction. The test checks for active transactions and, it not found, falls back to the non-XA API.
The test should only check for an existing transaction, whether active or not, and allow the TransactionManager to fail when invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBESB-3925) Please fix relative URL fixer in SOAPProxyWsdlLoader
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3925?page=com.atlassian.jira.plugin... ]
Tom Cunningham resolved JBESB-3925.
-----------------------------------
Resolution: Done
Checked into trunk in revision 38335.
> Please fix relative URL fixer in SOAPProxyWsdlLoader
> ----------------------------------------------------
>
> Key: JBESB-3925
> URL: https://issues.jboss.org/browse/JBESB-3925
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 4.12
> Environment: Any
> Reporter: Rick Wagner
> Assignee: Tom Cunningham
> Fix For: 4.13
>
>
> Method 'fixRelative' in SOAPProxyWsdlLoader doesn't act properly when a URL contains a single character component.
> Example: Looking for an XSD in a location like "/7/MySchema.xsd" will fail
> Please examine the attached Unit Test and implementation class diff file, apply if it's correct or enhance if it's lacking.
> Thank you!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBESB-3925) Please fix relative URL fixer in SOAPProxyWsdlLoader
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3925?page=com.atlassian.jira.plugin... ]
Tom Cunningham closed JBESB-3925.
---------------------------------
> Please fix relative URL fixer in SOAPProxyWsdlLoader
> ----------------------------------------------------
>
> Key: JBESB-3925
> URL: https://issues.jboss.org/browse/JBESB-3925
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 4.12
> Environment: Any
> Reporter: Rick Wagner
> Assignee: Tom Cunningham
> Fix For: 4.13
>
>
> Method 'fixRelative' in SOAPProxyWsdlLoader doesn't act properly when a URL contains a single character component.
> Example: Looking for an XSD in a location like "/7/MySchema.xsd" will fail
> Please examine the attached Unit Test and implementation class diff file, apply if it's correct or enhance if it's lacking.
> Thank you!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBESB-3939) FileStreamSplitter may lose a message during aggregation
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3939?page=com.atlassian.jira.plugin... ]
Tom Cunningham updated JBESB-3939:
----------------------------------
Fix Version/s: 4.11 CP2
> FileStreamSplitter may lose a message during aggregation
> --------------------------------------------------------
>
> Key: JBESB-3939
> URL: https://issues.jboss.org/browse/JBESB-3939
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transformation Service
> Affects Versions: 4.12
> Reporter: Kevin Conner
> Assignee: Tom Cunningham
> Fix For: 4.11 CP2
>
>
> The FileStreamSplitter incorrectly reports the number of messages that need to arrive at the aggregator as it should include the final message, containing the sequence count.
> If the final message is delivered out of order then this will result in one of the aggregated messages being dropped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBESB-3939) FileStreamSplitter may lose a message during aggregation
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3939:
-------------------------------------
Summary: FileStreamSplitter may lose a message during aggregation
Key: JBESB-3939
URL: https://issues.jboss.org/browse/JBESB-3939
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transformation Service
Affects Versions: 4.12
Reporter: Kevin Conner
Assignee: Tom Cunningham
The FileStreamSplitter incorrectly reports the number of messages that need to arrive at the aggregator as it should include the final message, containing the sequence count.
If the final message is delivered out of order then this will result in one of the aggregated messages being dropped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBESB-3926) FileStreamSplitter may lose a message during aggregation
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3926?page=com.atlassian.jira.plugin... ]
Tom Cunningham resolved JBESB-3926.
-----------------------------------
Assignee: Tom Cunningham
Resolution: Done
> FileStreamSplitter may lose a message during aggregation
> --------------------------------------------------------
>
> Key: JBESB-3926
> URL: https://issues.jboss.org/browse/JBESB-3926
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transformation Service
> Affects Versions: 4.12
> Reporter: Kevin Conner
> Assignee: Tom Cunningham
> Attachments: FileStreamSplitter.diff
>
>
> The FileStreamSplitter incorrectly reports the number of messages that need to arrive at the aggregator as it should include the final message, containing the sequence count.
> If the final message is delivered out of order then this will result in one of the aggregated messages being dropped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBESB-3930) NPE during deployment when Action in xsd is missing leading slash and validate option is true
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3930?page=com.atlassian.jira.plugin... ]
Tom Cunningham commented on JBESB-3930:
---------------------------------------
I'm not seeing this - when I remove the leading slash from publish_as_webservice, I get an error which points out which schema cannot be parsed.
5:56:54,224 ERROR [AbstractKernelController] Error installing to Start: name=jboss.esb.vfszip:/Users/tcunning/jboss-5.1.0.GA/server/default/deploy/Quickstart_publish_as_webservice.esb/ state=Create
org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Error configuring action processing pipeline
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:205)
at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133)
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:109)
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:66)
at org.jboss.soa.esb.listeners.deployers.mc.EsbDeployment.start(EsbDeployment.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
Caused by: org.jboss.soa.esb.ConfigurationException: Failed to parse the response schema: response.xsd
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.<init>(ActionProcessingPipeline.java:210)
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:199)
... 61 more
Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
Am I missing a step somewhere?
> NPE during deployment when Action in xsd is missing leading slash and validate option is true
> ---------------------------------------------------------------------------------------------
>
> Key: JBESB-3930
> URL: https://issues.jboss.org/browse/JBESB-3930
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 4.12
> Environment: jboss-5.1.0.GA, jbossesb 4.12
> Reporter: Richard Vachula
> Labels: action, esb, npe, nullpointerexception, schema, validate, xsd
>
> <actions inXsd="schemas/getUserInfo_in.xsd" mep="RequestResponse"
> outXsd="schemas/getUserInfo_out.xsd" validate="true" webservice="true">
> When inXsd or outXsd is missing leading slash / ("schemas/getUserInfo_in.xsd" instead of "/schemas/getUserInfo_in.xsd" deploy will result in NPE:
> Caused by: java.lang.NullPointerException
> at org.jboss.internal.soa.esb.util.XMLHelper.getSchema(XMLHelper.java:465)
> at org.jboss.internal.soa.esb.util.XMLHelper.getSchema(XMLHelper.java:418)
> at org.jboss.internal.soa.esb.util.XMLHelper.getSchema(XMLHelper.java:381)
> at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.<init>(ActionProcessingPipeline.java:197)
> at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:199)
> at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months