March 2010 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-556) Make the webservice_bpel quickstart into a Trailblazer

by Tom Fennelly (JIRA)

Make the webservice_bpel quickstart into a Trailblazer ------------------------------------------------------ Key: JBESB-556 URL: http://jira.jboss.com/jira/browse/JBESB-556 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.2 Milestone Release 2 Reporter: Tom Fennelly Assigned To: Tom Fennelly Fix For: 4.2 This is really a Trailblazer - too much in it to be a QS -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (JBESB-1691) MRG/RHM support

by Mark Little (JIRA)

MRG/RHM support --------------- Key: JBESB-1691 URL: http://jira.jboss.com/jira/browse/JBESB-1691 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.2.1 CP2 Reporter: Mark Little -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBESB-2846) bpm_orchestration2 process is not safe

by Kevin Conner (JIRA)

bpm_orchestration2 process is not safe -------------------------------------- Key: JBESB-2846 URL: https://jira.jboss.org/jira/browse/JBESB-2846 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.4 CP2 Reporter: Kevin Conner The bpm_orchestration2 quickstart is used to demonstrate fork/join operations in the business process but it is *not* safe. The forked actions are all configured to udpate the same process variable, providing an opportunity for contention. -- 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

14 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-3229) org.jboss.soa.esb.actions.Aggregator class does not forward the message id and service id received from the router.

by Mohit Mohta (JIRA)

org.jboss.soa.esb.actions.Aggregator class does not forward the message id and service id received from the router. ------------------------------------------------------------------------------------------------------------------- Key: JBESB-3229 URL: https://jira.jboss.org/jira/browse/JBESB-3229 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.4 CP3 Environment: Windows 7 Reporter: Mohit Mohta Fix For: 4.4 CP4 Hi, I have faced an issue that while using the org.jboss.soa.esb.actions.Aggregator class in my project i was getting an Null pointer exception in the MQMessage Router saying that it is not getting the message id and service name recevied from the message kept on the queue. To find out this i opened the org.jboss.soa.esb.actions.Aggregator.java in the src folder,where i found that in process method it creates a new message from the Message factory through a private Method createAggregateMessage(aggrDetails.getSeriesUuid(), messageMap).In this private method it is creating a new message without setting the message id and service name recevied from the original message.Like this. public Message createAggregateMessage(String uuId, Map<Integer, Message> messageMap) throws ActionProcessingException { // Create an aggregated message Message aggregatedMessage = MessageFactory.getInstance().getMessage();// Here creatng a new message without setting the previous message id. //Push additional AggregatorTags onto the new message, so we can aggregate in case of nested splits. //Only need to get it from the first message, should be the same for the others. List<String> aggregatedMessageTags = copyAggregationTags(messageMap); setAggregatorTags(aggregatedMessage, aggregatedMessageTags); for (Message attachmentMessage : messageMap.values()) { //Add the individual messages as attachments try { // Clear the aggregation tags from the attachment message. Any future aggregation // on the payload of these messages should be done within the context of the // outer/aggregated message and it's tags. setAggregatorTags(attachmentMessage, null); aggregatedMessage.getAttachment().addItem(Util.serialize(attachmentMessage)); } catch (ParserConfigurationException e) { throw new ActionProcessingException("Message attachment serialization failure", e); } catch (IOException e) { throw new ActionProcessingException("Message attachment serialization failure", e); } } synchronized (aggregatedMessageMap) { aggregatedMessageMap.remove(uuId); } //TODO remove messageMap from permanent storage, or do that per message in the loop above using value of the aggregatorTag //remove from the notificationMap if it is in there. return aggregatedMessage; } So what i did i explicitly passed the message id and service name to the newly created message.like this. String serviceName = message.getProperties().getProperty("serviceName").toString(); String MessageId = message.getProperties().getProperty("mqMessageId").toString(); // Details from the prevoius message. Then passed this to the new message.like this message = createAggregateMessage(aggrDetails.getSeriesUuid(), messageMap); message.getProperties().setProperty("mqMessageId", MessageId); message.getProperties().setProperty("serviceName", serviceName); After this my problem of getting Null Pointer exceptiongot resolved. Request to the person to resolve this issue/bug with Aggregator class. Regards Mohit -- 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

14 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBESB-3197) Service Invoker load balance policy that prefers local EPRs

by Kevin Conner (JIRA)

Service Invoker load balance policy that prefers local EPRs ------------------------------------------------------------ Key: JBESB-3197 URL: https://jira.jboss.org/jira/browse/JBESB-3197 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.4 CP3 Reporter: Kevin Conner Fix For: 4.4 CP4 -- 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

14 years, 9 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-2558) monitoring.cfg.xml not found

by Kevin Conner (JIRA)

monitoring.cfg.xml not found ----------------------------- Key: JBESB-2558 URL: https://jira.jboss.org/jira/browse/JBESB-2558 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Management Reporter: Kevin Conner Fix For: 4.6 The configuration of the management services is currently broken, leaving an opportunity for the following exception to be thrown. org.hibernate.HibernateException: monitoring.cfg.xml not found at org.hibernate.util.ConfigHelper.getResourceAsStream(ConfigHelper.java:147) at org.hibernate.cfg.Configuration.getConfigurationInputStream(Configuration.java:1405) at org.hibernate.cfg.Configuration.configure(Configuration.java:1427) at org.jboss.soa.esb.monitoring.MonitoringSessionFactory.init(MonitoringSessionFactory.java:80) at org.jboss.soa.esb.monitoring.MonitoringSessionFactory.getInstance(MonitoringSessionFactory.java:68) at org.jboss.soa.esb.monitoring.client.OperationsCollector.getClassPatterns(OperationsCollector.java:84) at org.jboss.soa.esb.monitoring.client.OperationsCollector.collectData(OperationsCollector.java:165) at org.jboss.soa.esb.monitoring.client.OperationsCollectorAction.collectOperations(OperationsCollectorAction.java:72) The reason for this issue is that the monitoring services specified in jbossesb.esb have an implicit dependency on a jar provided in management.esb but management.esb has an explicit dependency on jbossesb.esb. This will, therefore, leave a window where the management configuration may be required *before* the jar has been loaded. The implicit dependency is caused by the requirement of jbossesb.esb/management-client.jar to access the monitoring.cfg.xml file included in management.esb/management-server.jar. -- 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

14 years, 9 months

2
7
0 / 0

[JBoss JIRA] Created: (JBESB-3255) WSDL unavailable for SOAPProxy + HTTPGateway on server restarts

by David Ward (JIRA)

WSDL unavailable for SOAPProxy + HTTPGateway on server restarts --------------------------------------------------------------- Key: JBESB-3255 URL: https://jira.jboss.org/jira/browse/JBESB-3255 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.7 CP2 Reporter: David Ward Assignee: David Ward Fix For: 4.7 CP2 When hot-deploying or re-deploying an .esb archive with SOAPProxy + HTTPGateway, the WSDL shows up in the contract JSP application no problem. However, when re-starting the server (and leaving the .esb archive in deploy), the WSDL does NOT show up in the JSP. This does NOT affect the service from working, as it still gets deployed and still functions. The problem is the missing WSDL. The problem is in: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/branches/JBESB_4_7_CP/p... (as well as mappers 110 and 100). In mappers120, line 608 is throwing a ClassNotFoundExeption, then falling into Line 610. The class it's looking for, of course, is "org.jboss.soa.esb.actions.soap.proxy.SOAPProxy". The fix is probably simple: make sure the right thread context class loader is in effect. -- 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

14 years, 9 months

2
11
0 / 0

[JBoss JIRA] Created: (JBESB-1429) Need an MBean for CronExpressions

by Tom Cunningham (JIRA)

Need an MBean for CronExpressions --------------------------------- Key: JBESB-1429 URL: http://jira.jboss.com/jira/browse/JBESB-1429 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Management Affects Versions: 4.2.1 Reporter: Tom Cunningham Assigned To: Tom Cunningham Need a way of dynamically updating a cron expression at runtime. MBean probably would be the preferable method for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
4
0 / 0

[JBoss JIRA] Created: (JBESB-3258) Remote ServiceInvoker fails when using 4.7 jbossesb-rosetta.jar

by Scott Dawson (JIRA)

Remote ServiceInvoker fails when using 4.7 jbossesb-rosetta.jar --------------------------------------------------------------- Key: JBESB-3258 URL: https://jira.jboss.org/jira/browse/JBESB-3258 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.7 Environment: jbossesb-server-4.7, JDK 1.5 or 1.6 Reporter: Scott Dawson Using a simple remote ServiceInvoker client like the one described in the Programmer's Guide ('Configuration for a remote ServiceInvoker') to invoke the helloworld quickstart, if the client uses the jbossesb-rosetta.jar from jbossesb-server-4.7/server/default/deploy/jbossesb.sar/lib, then the service invocation fails with: org.jboss.soa.esb.listeners.message.MessageDeliverException: org.apache.ws.scout.transport.TransportException: java.lang.Exception: org.jboss.internal.soa.esb.registry.client.JuddiRMITransport This appears to happen during the creation of the ServiceInvoker object, so the call to deliverAsync never happens. Switching to a more recent jbossesb-rosetta.jar built from trunk solves the problem, so the issue seems to be with the out-of-the-box 4.7 jar. Based on posts in the user forum it seems a number of people are experiencing the problem. See the Forum Reference for more information. Here is a more complete stack trace: org.jboss.soa.esb.listeners.message.MessageDeliverException: org.apache.ws.scout.transport.TransportException: java.lang.Exception: org.jboss.internal.soa.esb.registry.client.JuddiRMITransport at org.jboss.soa.esb.client.ServiceInvoker.loadServiceClusterInfo(ServiceInvoker.java:545) at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:174) at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:155) at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:197) at EsbClient.main(EsbClient.java:16) Caused by: org.jboss.soa.esb.services.registry.RegistryException: org.apache.ws.scout.transport.TransportException: java.lang.Exception: org.jboss.internal.soa.esb.registry.client.JuddiRMITransport at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.findEPRs(JAXRRegistryImpl.java:348) at org.jboss.internal.soa.esb.services.registry.InVMRegistryInterceptor.findEPRs(InVMRegistryInterceptor.java:85) at org.jboss.soa.esb.services.registry.RegistryFactory$HeadRegistryInterceptor.findEPRs(RegistryFactory.java:229) at org.jboss.soa.esb.listeners.RegistryUtil.getEprs(RegistryUtil.java:226) at org.jboss.soa.esb.client.ServiceInvoker.loadServiceClusterInfo(ServiceInvoker.java:532) ... 4 more Caused by: javax.xml.registry.JAXRException: org.apache.ws.scout.transport.TransportException: java.lang.Exception: org.jboss.internal.soa.esb.registry.client.JuddiRMITransport at org.apache.ws.scout.registry.BusinessQueryManagerV3Impl.findConcepts(BusinessQueryManagerV3Impl.java:516) at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.getJBossESBTModel(JAXRRegistryImpl.java:653) at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.findEPRs(JAXRRegistryImpl.java:307) ... 8 more -- 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

14 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-2550) "local first" load balancing policy

by toby cabot (JIRA)

"local first" load balancing policy ----------------------------------- Key: JBESB-2550 URL: https://jira.jboss.org/jira/browse/JBESB-2550 Project: JBoss ESB Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 4.4 Reporter: toby cabot Here's a patch that adds org.jboss.soa.esb.listeners.ha.LocalFirstRoundRobin which will choose a local EPR if there is one and fall back to RoundRobin if not. We like this because it keeps processing on a single host when that's possible and only goes off-host (which is relatively expensive) if necessary. -- 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

14 years, 9 months

4
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues March 2010