[JBoss JIRA] Created: (JBESB-1851) JAXRConnectionFactory should not rely on System properties when creating a Connection
by Daniel Bevenius (JIRA)
JAXRConnectionFactory should not rely on System properties when creating a Connection
-------------------------------------------------------------------------------------
Key: JBESB-1851
URL: http://jira.jboss.com/jira/browse/JBESB-1851
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Examples, Registry and Repository
Reporter: Daniel Bevenius
The quickstarts that use the ServiceInvoker all seem to do this (atleast the ones that I've looked at) :
System.setProperty("javax.xml.registry.ConnectionFactoryClass","org.apache.ws.scout.registry.ConnectionFactoryImpl");
Now, we have this property in the jbossesb-properties.xml as:
<property name="org.jboss.soa.esb.registry.factoryClass" value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/>
This property is read by JAXRConnectionFactory constructor and saved into a Properties object as:
props.setProperty("javax.xml.registry.factoryClass", Configuration.getRegistryFactoryClass());
The 'props' are set on the ConnectionFactory object that is created in the getConnection() method:
protected Connection getConnection()
{
Connection connection = null;
try
{ // Create the connection, passing it the configuration properties
ConnectionFactory factory = ConnectionFactory.newInstance();
factory.setProperties(props);
connection = factory.createConnection();
connection.setCredentials(creds);
} catch (JAXRException e) {
logger.log(Level.ERROR, "Could not set up a connection to the Registry. " + e.getMessage(), e);
}
return connection;
}
Here we can see that ConnectionFactory.newInstance() method will be called prior to the properties getting set on the factory, which is
natural. But the problem is that ConnectionFactory.newInstance() method looks like this:
private static final String SYS_PROP_NAME = "javax.xml.registry.ConnectionFactoryClass";
public static ConnectionFactory newInstance() throws JAXRException
{
String factoryName = null;
ConnectionFactory factory = null;
try
{
String defaultName = null;
factoryName = System.getProperty(SYS_PROP_NAME, defaultName);
ClassLoader loader =Thread.currentThread().getContextClassLoader();
Class factoryClass = loader.loadClass(factoryName);
factory = (ConnectionFactory) factoryClass.newInstance();
}
catch(Throwable e)
{
throw new JAXRException("Failed to create instance of:"+factoryName, e);
}
return factory;
}
We should not be relying on the system properties in order to do this.
Our JAXRConnectionFactory should be creating the factory directly and
not using ConnectionFactory, this is the real error IMO. If we do this
then we will not be affected by anyone else in the AS overriding JAXR.
Kev
See also this googlegroups thread for more background info: http://groups.google.se/group/jbossesb/browse_frm/thread/3a5ce28b4a0f6bca
--
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
16 years, 1 month
[JBoss JIRA] Created: (JBESB-2329) FTP Gateway: error-delete does not work
by Thomas Guenter (JIRA)
FTP Gateway: error-delete does not work
---------------------------------------
Key: JBESB-2329
URL: https://jira.jboss.org/jira/browse/JBESB-2329
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Adapters
Affects Versions: 4.4
Environment: jbossesb-server-4.4.GA on Mac OS 10.5
Reporter: Thomas Guenter
Priority: Minor
If the error-delete attribute in a ftp-message-filter is set to "true" (as default), it is expected that no error file will be generated at all. Instead an error file with the default error-suffix is created in the (input-)directory.
Since the logic that handles these issues is implemented in the class org.jboss.soa.esb.listeners.gateway.AbstractFileGateway, it is likely that the FileGatewayListener is also affected but this hasn't been tested yet.
--
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
16 years, 1 month
[JBoss JIRA] Created: (JBESB-2204) jBPM Persistence race condition in EsbActionHandler under high load
by Damon Brown (JIRA)
jBPM Persistence race condition in EsbActionHandler under high load
-------------------------------------------------------------------
Key: JBESB-2204
URL: https://jira.jboss.org/jira/browse/JBESB-2204
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.4
Environment: AS 4.2.3.GA, jBPM 3.2.3.GA + ehcache, RHEL 5, x86_64, 1.6.0 Sun JVM, Oracle 10g
Reporter: Damon Brown
Priority: Minor
Attachments: CallbackCommand.java.patch
Under extremely high load, the org.jboss.soa.esb.services.jbpm.cmd.CallbackCommand:90 cannot always locate the Token to signal for the target process. The exception is not propagated to the CallbackQueue and the message is not retried. The target process is left in a suspended state even though the ESB service has completed its action. The failure rate is machine-load dependent (1 - 5% failure rate).
The root cause of the missing token is not able to be attributed to the jBPM hibernate session directly. I extended org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler directly to forcibly flush the current state of the token to the database. Within the same action, I queried for the state of the object, which was returned successfully.
There appears to be a race condition from ESB service invocation (EsbActionHandler), token persistence (hibernate flush), and command callback (CallbackCommand). The particular ESB service I am invoking has a short suspense. Other ESB services, which take longer to execute, do not exhibit this behavior. The behavior for the short-suspense service was random, but repeatable.
The patch file attached to this issue attempts to resolve the issue by re-trying the token look-up three times with an intermittent sleep. Within my environment, under high load conditions, the token failed to resolve on the first try 1% - 5% of the time (98% average success on first try), with a 100% success rate on the second try. The target process instance is successfully signaled.
--
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
16 years, 1 month
[JBoss JIRA] Created: (JBESB-1972) EBWS endpoints are created even if ESB config file is onvalid
by Jiri Pechanec (JIRA)
EBWS endpoints are created even if ESB config file is onvalid
-------------------------------------------------------------
Key: JBESB-1972
URL: https://jira.jboss.org/jira/browse/JBESB-1972
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Web Services
Affects Versions: 4.4 CP1
Reporter: Jiri Pechanec
Priority: Critical
If there is a validation error in ESB config file the EBWS endpoints are created and their WSDL is accessible
2008-09-01 12:59:17,623 WARN [org.jboss.system.ServiceController] Problem starting service jboss.esb:deployment=EBWS.esb
java.lang.RuntimeException: java.lang.IllegalStateException: ESB file had validation errors.
at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:138)
at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployment.startService(JBoss4ESBDeployment.java:99)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor333.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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor9.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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:588)
at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:562)
at sun.reflect.GeneratedMethodAccessor364.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.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.GeneratedMethodAccessor317.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: java.lang.IllegalStateException: ESB file had validation errors.
at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:132)
... 80 more
2008-09-01 12:59:17,632 INFO [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/EBWS, warUrl=.../tmp/deploy/esbwarfiles/EBWS.esb/EBWS-exp.war/
2008-09-01 12:59:18,060 INFO [org.jboss.wsf.stack.jbws.WSDLFilePublisher] WSDL published to: file:/home/jpechane/pokus/43IR2AS/jboss-as/server/postgresql/data/wsdl/EBWS.esb/EBWS.war/esbservicesample_helloworldpubservice.wsdl
2008-09-01 12:59:18,068 INFO [org.jboss.wsf.stack.jbws.WSDLFilePublisher] WSDL published to: file:/home/jpechane/pokus/43IR2AS/jboss-as/server/postgresql/data/wsdl/EBWS.esb/EBWS.war/esbservicesample_requestreply.wsdl
2008-09-01 12:59:18,073 INFO [org.jboss.wsf.stack.jbws.WSDLFilePublisher] WSDL published to: file:/home/jpechane/pokus/43IR2AS/jboss-as/server/postgresql/data/wsdl/EBWS.esb/EBWS.war/esbservicesample_oneway.wsdl
--
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
16 years, 1 month
[JBoss JIRA] Created: (JBESB-1992) EBWS Security needs rework and unification
by Jiri Pechanec (JIRA)
EBWS Security needs rework and unification
------------------------------------------
Key: JBESB-1992
URL: https://jira.jboss.org/jira/browse/JBESB-1992
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Security, Web Services
Affects Versions: 4.4
Reporter: Jiri Pechanec
There is now security implementation at two levels
- specifying webservice="security" attribute enables JBossWS security handler
- specifying security elemnt enables WSSecuritySoapExtractor
The WSSecuritySoapExtractor operates at XML/DOM level which means that is completely independent on JBossWS security handler.
Please consider unifying the configuration and JBossWS facility use.
Morever check the WSSecurityInfoExtractor if there is also a way to use JBossWS functions instead of Smooks parsing.
--
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
16 years, 1 month