September 2010 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-3485) Clear up missing imports when generating javadocs

by Kevin Conner (JIRA)

Clear up missing imports when generating javadocs ------------------------------------------------- Key: JBESB-3485 URL: https://jira.jboss.org/browse/JBESB-3485 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Build and Release Affects Versions: 4.9 Reporter: Kevin Conner Priority: Minor Fix For: 4.9 CP1 sxc, camel and other imports are missing from the javadoc task -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-2805) Splitter EAI Pattern: A router that really split the message and delivery the message parts to different message channels

by Ricardo Ferreira (JIRA)

Splitter EAI Pattern: A router that really split the message and delivery the message parts to different message channels ------------------------------------------------------------------------------------------------------------------------- Key: JBESB-2805 URL: https://jira.jboss.org/jira/browse/JBESB-2805 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Content Based Routing Affects Versions: 4.6, 4.5, 4.4 Reporter: Ricardo Ferreira Current JBoss ESB Routers (StaticRouter and StaticWiretap) does not implement fully the EAI Patterns Splitter (http://www.eaipatterns.com/Sequencer.html). Those implementations just take the incoming message and redelivery for diferent services using basic routing. But in the pattern description we found: "Use a Splitter to BREAK OUT the composite message into a series of INDIVIDUAL MESSAGES, each containing data related to one item" The proposal is to implement a generic Splitter (org.jboss.soa.esb.actions.Splitter) that takes a message, and, using Smooks, separate the message onto diferent messages (individual messages) and send those individual messages to others message channels. Here's a example of this action: <action name="splitter" class="org.jboss.soa.esb.actions.Splitter"> <property name="destinations"> <route-to service-category="Enterprise Business Services" service-name="FirstService"> <message-splitter smooksConfig="/META-INF/smooks-res-1.xml" resultType="STRING" /> </route-to> <route-to service-category="Enterprise Business Services" service-name="SecondService"> <message-splitter smooksConfig="/META-INF/smooks-res-2.xml" resultType="JAVA" /> </route-to> </property> </action> I've implemented this action and it is fully working in the following enviroment: OS: Red Hat Enterprise Linux 5 JVM: Sun JDK 1.5-16 JBoss ESB 4.5 I would like that this feature would be available in the JBoss ESB and the SOA Platform product, since, I've customers that asked me for this kind of feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
8
0 / 0

[JBoss JIRA] Created: (JBESB-3494) Misspelled Classname in documentation for org.jboss.soa.esb.actions.ContentBasedWiretap

by Peer Bech Hansen (JIRA)

Misspelled Classname in documentation for org.jboss.soa.esb.actions.ContentBasedWiretap --------------------------------------------------------------------------------------- Key: JBESB-3494 URL: https://jira.jboss.org/browse/JBESB-3494 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.9 Environment: Jboss ESB 4.9 Reporter: Peer Bech Hansen Priority: Minor In the Service Guide documentation the class org.jboss.soa.esb.actions.ContentBasedWiretap is misspelled In http://docs.jboss.org/jbossesb/docs/4.9/manuals/html/Services_Guide/index... in chapter 3.4.2, point 2, ContentBasedWiretap is spelled with capital T in Tap. T should be lower case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-3391) SoapUIClientService transforms targeted at #document fragment are lost because SoapUIClientServicealready holds a ref to the old DOM Document root element

by Tom Fennelly (JIRA)

SoapUIClientService transforms targeted at #document fragment are lost because SoapUIClientServicealready holds a ref to the old DOM Document root element ---------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBESB-3391 URL: https://jira.jboss.org/browse/JBESB-3391 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transformation Service Affects Versions: 4.8, 4.9 Reporter: Tom Fennelly Assignee: Tom Fennelly Fix is very easy.... just modify the SoapUIClientService.buildSOAPMessage() where if calls Smooks ... as follows... From... if(smooksResource != null) { applySmooksTransform(smooksResource, messageDoc); } To... if(smooksResource != null) { applySmooksTransform(smooksResource, messageDoc); // reassign the docRoot variable after transform... in case it was replaced by a #document transform... docRoot = messageDoc.getDocumentElement(); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-3472) Broken dependencies between ESB and HornetQ deployments

by Martin Vecera (JIRA)

Broken dependencies between ESB and HornetQ deployments ------------------------------------------------------- Key: JBESB-3472 URL: https://jira.jboss.org/browse/JBESB-3472 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment Affects Versions: 4.9 Reporter: Martin Vecera Attachments: Quickstart_Aggregator5.esb.tar.bz2 I have a an exploded ESB deployment that contains hornetq-jms.xml deploying some queues and deployment.xml specifying dependencies on those queues. Every other try, the deployment fails with an exception (see below). Steps to reproduce are just copying the attached deployment to the deploy directory and deleting several times in a row. 14:24:11,737 ERROR [AbstractKernelController] Error installing to Start: name=jboss.esb.vfsfile:/qa/home/mvecera/work/soa/510Dev3/jboss-as/server/production/deploy/Quickstart_Aggregator5.esb/ state=Create org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Unexpected JMS error from prepareMessageReceiver at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.doInitialise(JmsGatewayListener.java:122) 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:223) at sun.reflect.GeneratedMethodAccessor598.invoke(Unknown Source) 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:243) at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:111) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) 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:1652) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:938) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:988) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:778) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:543) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:125) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:52) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1454) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1172) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1193) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1113) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1652) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:938) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:988) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:826) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:556) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:789) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:699) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:409) at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:294) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) 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:181) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: javax.jms.JMSException: There is no queue with name queue/quickstart_Aggregator5_Request_GW at org.hornetq.jms.client.HornetQSession.createQueue(HornetQSession.java:399) 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.internal.soa.esb.rosetta.pooling.JmsSession$ExceptionHandler.invoke(JmsSession.java:492) at $Proxy335.createQueue(Unknown Source) at org.jboss.internal.soa.esb.rosetta.pooling.JmsSession.createQueue(JmsSession.java:221) at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.prepareMessageReceiver(JmsGatewayListener.java:433) at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.doInitialise(JmsGatewayListener.java:114) ... 57 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-3440) Smooks 1.2 JavaBean namespace with wise SoapClient causes ClassNotFoundException

by Toshiya Kobayashi (JIRA)

Smooks 1.2 JavaBean namespace with wise SoapClient causes ClassNotFoundException -------------------------------------------------------------------------------- Key: JBESB-3440 URL: https://jira.jboss.org/browse/JBESB-3440 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.7 CP2 Reporter: Toshiya Kobayashi I'm using the wise SoapClient to call an external SOAP web service. The ESB service itself is exposed as web service as well, but using a different XSD, and only OneWay. Smooks is used to transform the input XML SOAP message into the format that the external web service wants. Since wise wants it's message as JAXB-objects, the Smooks transformation is configured to instantiate the wise-generated JAXB classes. When writing this as resource-config tags (smooks-1.0.xsd namespace), it works correctly. However, when using the much shorter and preferred jb:bean tags (javabean-1.2.xsd namespace), ClassNotFoundException occurs while deploying the .ESB service: Smooks can't find the generated classes. This makes sense, since Wise won't create them until the first request. Apparently the behaviour is quite different between the 1.0 and the 1.2 notation, while using the same Smooks runtime. 1.0 Behaviour: - During .ESB deployment, the configuration is only parsed. No classes are loaded. - With the first request, Wise creates JAXB sources. - While transforming, Smooks classloads the JAXB classes. 1.2 Behaviour: - During .ESB deployment, classes in the configuration are already classloaded. Hence, ClassNotFoundException. =========== This is the older version of the WISE SOAPClient, released pre Smooks v1.1 (when the extended namespace configs were introduced). So, it probably wouldn't have been tested against the newer features in the newer versions of Smooks i.e. may not be forward compatible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
10
0 / 0

[JBoss JIRA] Created: (JBESB-3490) ProcessLogs that represent changes of process intance that take place within Timer.Execute are not saved in DB

by Kevin Conner (JIRA)

ProcessLogs that represent changes of process intance that take place within Timer.Execute are not saved in DB -------------------------------------------------------------------------------------------------------------- Key: JBESB-3490 URL: https://jira.jboss.org/browse/JBESB-3490 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.7 CP2 Reporter: Toshiya Kobayashi Log events won't be saved when they are triggered by Timer. This issue was fixed in JobExecutorThread ( JBPM-1015 ). But regarding SOA integration, only org.jboss.soa.esb.services.jbpm.integration.job.ExecuteJobCommand includes the fix. org.jboss.soa.esb.services.jbpm.integration.job.ExecuteTimerCommand should follow. # Snippet from org.jboss.soa.esb.services.jbpm.integration.job.ExecuteJobCommand // register process instance for automatic save // see https://jira.jboss.org/jira/browse/JBPM-1015 ProcessInstance processInstance = job.getProcessInstance(); jbpmContext.addAutoSaveProcessInstance(processInstance); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-3488) init.classpath in soap services does not initialise exec.classpath

by Kevin Conner (JIRA)

init.classpath in soap services does not initialise exec.classpath ------------------------------------------------------------------ Key: JBESB-3488 URL: https://jira.jboss.org/browse/JBESB-3488 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Build and Release Affects Versions: 4.9 CP1 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.9 CP1 My bad, missed as part of JBESB-3484. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-2849) Add caching of JAXR connections

by Kevin Conner (JIRA)

Add caching of JAXR connections ------------------------------- Key: JBESB-2849 URL: https://jira.jboss.org/jira/browse/JBESB-2849 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Registry and Repository Affects Versions: 4.6 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.7 These are heavyweight objects, especially when integrating juddi v3. We should be caching these to reduce the impact. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-3484) SOAPProcessor relies on new JBossWS CXF feature, not present in SOA

by Kevin Conner (JIRA)

SOAPProcessor relies on new JBossWS CXF feature, not present in SOA ------------------------------------------------------------------- Key: JBESB-3484 URL: https://jira.jboss.org/browse/JBESB-3484 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.9 Reporter: Kevin Conner Assignee: Kevin Conner Priority: Blocker Fix For: 4.9 CP1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues September 2010