September 2008 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view

by Jiri Pechanec (JIRA)

The InVM courier is not completely valid from concurrency point of view ----------------------------------------------------------------------- Key: JBESB-1944 URL: https://jira.jboss.org/jira/browse/JBESB-1944 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.4 Reporter: Jiri Pechanec Fix For: 4.4 CP1 There are few problems with current implementation of InVM courier. 1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately the synchronized primitive is used as lock on this queue whicm means that all advanatages of using it are negated. I guess that this approch is used for lockstep. The correct soultion is should be to have messageQueue unsychchronized and have separate Event object or separate regular object as lock holder if lockstep is in place. 2) The lockstep does not work correctly when there are multiple threads on input/output of the queue. The notify call does not guarantee that the correct delivery/pickup threads are waken up. For example the notify call in one delivery thread can wake up another delivery thread waiting up for the notify from pickup thread. -- 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

17 years, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (JBESB-2008) Security context propagation

by Kevin Conner (JIRA)

Security context propagation ---------------------------- Key: JBESB-2008 URL: https://jira.jboss.org/jira/browse/JBESB-2008 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Security Affects Versions: 4.4 CP1 Reporter: Kevin Conner Assignee: Daniel Bevenius Fix For: 4.4 CP1 The security context is currently being propagated through the pipeline by attaching it to the original message. Unfortunately there is no guarantee that the original message will be used past the first action and we would, therefore, lose the context. We need to have the context associated with the current thread and then intercept outgoing messages to reapply it. This is further complicated by the InVM courier which could pass the message by reference. -- 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

17 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-2007) Add automatic authorisation into the pipeline

by Kevin Conner (JIRA)

Add automatic authorisation into the pipeline --------------------------------------------- Key: JBESB-2007 URL: https://jira.jboss.org/jira/browse/JBESB-2007 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Security Affects Versions: 4.4 CP1 Reporter: Kevin Conner Assignee: Daniel Bevenius Fix For: 4.4 CP1 The pipeline does not currently do automatic authorisation of the security context, instead it is left up to the actions to handle. -- 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

17 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBESB-2009) Improve authentication processing in the ESB

by Kevin Conner (JIRA)

Improve authentication processing in the ESB -------------------------------------------- Key: JBESB-2009 URL: https://jira.jboss.org/jira/browse/JBESB-2009 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Security Affects Versions: 4.4 CP1 Reporter: Kevin Conner Assignee: Daniel Bevenius Fix For: 4.4 CP1 The current implementation is executing the security authentication on every invocation. We should be able to identify pre-authenticated contexts and re-use these instead of authenticating on each invocation. These contexts should only be trusted if they were generated in the same VM, foreign contexts should be re-authenticated. -- 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

17 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBESB-1986) EBWS It is not possible to have services with the same name but different category

by Jiri Pechanec (JIRA)

EBWS It is not possible to have services with the same name but different category ---------------------------------------------------------------------------------- Key: JBESB-1986 URL: https://jira.jboss.org/jira/browse/JBESB-1986 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.4 Reporter: Jiri Pechanec This config <service category="Unsecured" name="RequestReply" description="Hello world ESB Service" invmScope="GLOBAL"> <actions mep="RequestResponse" inXsd="/request.xsd" outXsd="/response.xsd" faultXsd="/fault.xsd"> <action name="action" class="org.jboss.soa.esb.samples.quickstart.ebws.MyJMSListenerAction" process="displayMessage" /> </actions> </service> <service category="SecuredLogin" name="RequestReply" description="Hello world ESB Service" invmScope="GLOBAL"> <actions mep="RequestResponse" inXsd="/request.xsd" outXsd="/response.xsd" faultXsd="/fault.xsd"> <action name="action" class="org.jboss.soa.esb.samples.quickstart.ebws.MyJMSListenerAction" process="displayMessage" /> </actions> </service> Generates this exception 2008-09-04 13:11:24,198 ERROR [org.jboss.deployment.MainDeployer] Could not initialise deployment: file:/home/jpechane/testing/esbtests/tests/quickstarts/tests/output/lib/EBWS.esb org.jboss.deployment.DeploymentException: Failed to create webservice artifact; - nested throwable: (org.jboss.internal.soa.esb.webservice.WebServicePublishException: Duplicate class within context: esb.ws.requestreply.Implementation) at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.createWebserviceWars(JBoss4ESBDeployer.java:574) at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.init(JBoss4ESBDeployer.java:299) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:872) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:809) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:566) 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:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266) at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74) at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:108) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179) at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:818) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:419) at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) Caused by: org.jboss.internal.soa.esb.webservice.WebServicePublishException: Duplicate class within context: esb.ws.requestreply.Implementation at org.jboss.internal.soa.esb.webservice.JAXWSProviderClassGenerator.generate(JAXWSProviderClassGenerator.java:60) at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.createWebserviceWars(JBoss4ESBDeployer.java:533) ... 55 more The problem is in ESBServiceEndpointInfo packageName = "esb.ws." + serviceNameLower ; className = packageName + ".Implementation" ; The package name shoould consist also of category name -- 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

17 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-2030) Add version to plugin

by Tom Cunningham (JIRA)

Add version to plugin --------------------- Key: JBESB-2030 URL: https://jira.jboss.org/jira/browse/JBESB-2030 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Management Reporter: Tom Cunningham Assignee: Tom Cunningham Add version to the plugin. See related SOA issue. -- 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

17 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-2032) Migrate jonplugin code changes across to CP

by Kevin Conner (JIRA)

Migrate jonplugin code changes across to CP ------------------------------------------- Key: JBESB-2032 URL: https://jira.jboss.org/jira/browse/JBESB-2032 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Management Affects Versions: 4.4 CP1 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.4 CP1 Some of the jonplugin changes have been made in trunk, we need to migrate them across to the CP branch -- 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

17 years, 7 months

1
1
0 / 0

[JBoss JIRA] Work started: (JBESB-1941) InVM lock is held unnecessarily long time

by Mark Little (JIRA)

[ https://jira.jboss.org/jira/browse/JBESB-1941?page=com.atlassian.jira.plu... ] Work on JBESB-1941 started by Mark Little. > InVM lock is held unnecessarily long time > ----------------------------------------- > > Key: JBESB-1941 > URL: https://jira.jboss.org/jira/browse/JBESB-1941 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Rosetta, Transports > Affects Versions: 4.4 > Reporter: Jiri Pechanec > Assignee: Mark Little > Priority: Minor > Fix For: 4.4 CP1 > > > If the pass by value is used the message is serialized/deserialized. The process of (de)serialization is done when the lock on messageQueue is held. This is not necessary as the act itself can be done out of the lock. It can improve the performance for this cases. -- 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

17 years, 7 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBESB-1941) InVM lock is held unnecessarily long time

by Jiri Pechanec (JIRA)

[ https://jira.jboss.org/jira/browse/JBESB-1941?page=com.atlassian.jira.plu... ] Jiri Pechanec reopened JBESB-1941: ---------------------------------- Serialization is still done in synchronized block > InVM lock is held unnecessarily long time > ----------------------------------------- > > Key: JBESB-1941 > URL: https://jira.jboss.org/jira/browse/JBESB-1941 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Rosetta, Transports > Affects Versions: 4.4 > Reporter: Jiri Pechanec > Assignee: Mark Little > Priority: Minor > Fix For: 4.4 CP1 > > > If the pass by value is used the message is serialized/deserialized. The process of (de)serialization is done when the lock on messageQueue is held. This is not necessary as the act itself can be done out of the lock. It can improve the performance for this cases. -- 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

17 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-2029) Ivy changes for JBESB-1988 cause a clean ivy build to fail

by Kevin Conner (JIRA)

Ivy changes for JBESB-1988 cause a clean ivy build to fail ---------------------------------------------------------- Key: JBESB-2029 URL: https://jira.jboss.org/jira/browse/JBESB-2029 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Build and Release Affects Versions: 4.4 CP1, 4.5 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.4 CP1, 4.5 The reason for one of the changes is that the mvel pom.xml does not match the hierarchy in which it is found. This causes ivy to reject the configuration. I thought I had fixed this issue but my changes actually broke the build. This was hidden from me/CI as we had already downloaded the appropriate metadata. The real way to fix this is to change the mvel organisation to org.codehaus.mvel (reflecting the pom organisation) and include a module definition in the ivysettings which will override the normal path configuration of the m2 repository. My bad, apologies to all. -- 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

17 years, 7 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues September 2008