[JBoss JIRA] Created: (JBAS-6188) fix "java.lang.IllegalArgumentException: Wrong arguments. setUseTryLock for target org.jboss.resource.metadata.mcf .LocalDataSourceDeploymentMetaData@75687c expected=[long] actual=[null]" error on call to profileView.applyTemplate() for new datasource
by Ian Springer (JIRA)
fix "java.lang.IllegalArgumentException: Wrong arguments. setUseTryLock for target org.jboss.resource.metadata.mcf .LocalDataSourceDeploymentMetaData@75687c expected=[long] actual=[null]" error on call to profileView.applyTemplate() for new datasource
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-6188
URL: https://jira.jboss.org/jira/browse/JBAS-6188
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: ProfileService
Environment: AS5 build from Hudson dated 200811070836
Reporter: Ian Springer
Assignee: Scott M Stark
The property in question, "use-try-lock", has a value of null, which should be fine since its isMandatory() method returns false. However, it appears from the error message that the underlying property is a primitive long and so it chokes when the value is null.
Here's the stack trace (including the WARN message that occurs a bit earlier in case it's either related or is a separate issue that can be fixed):
15:44:33,530 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{
jndi-name,jndiName,metaType=SimpleMetaType:java.lang.String}, value=null
15:44:33,530 ERROR [ProfileJBossServerComponent] Unable to apply Template and process through Profile View
java.lang.reflect.UndeclaredThrowableException
at org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:277
)
at org.jboss.managed.plugins.WritethroughManagedPropertyImpl.setValue(WritethroughManagedPropertyImpl.java:109)
at org.jboss.resource.deployers.management.DsDataSourceTemplate.writeTemplate(DsDataSourceTemplate.java:154)
at org.jboss.resource.deployers.management.DsDataSourceTemplate.applyTemplate(DsDataSourceTemplate.java:70)
at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:673)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:623)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:67)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1708)
at org.jboss.remoting.Client.invoke(Client.java:612)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at AOPProxy$1.applyTemplate(AOPProxy$1.java)
at org.rhq.plugins.jbossas5.ProfileJBossServerComponent.createConfigurationBasedResource(ProfileJBossServerCompo
nent.java:235)
at org.rhq.plugins.jbossas5.ProfileJBossServerComponent.createResource(ProfileJBossServerComponent.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:623)
at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:450)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:713)
Caused by: java.lang.IllegalArgumentException: Wrong arguments. setUseTryLock for target org.jboss.resource.metadata.mcf
.LocalDataSourceDeploymentMetaData@75687c expected=[long] actual=[null]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:395)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:69)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143)
at org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:378
)
at org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:273
)
at org.jboss.managed.plugins.WritethroughManagedPropertyImpl.setValue(WritethroughManagedPropertyImpl.java:109)
at org.jboss.resource.deployers.management.DsDataSourceTemplate.writeTemplate(DsDataSourceTemplate.java:154)
at org.jboss.resource.deployers.management.DsDataSourceTemplate.applyTemplate(DsDataSourceTemplate.java:70)
at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:673)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:623)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:67)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1708)
at org.jboss.remoting.Client.invoke(Client.java:612)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at AOPProxy$1.applyTemplate(AOPProxy$1.java)
at org.rhq.plugins.jbossas5.ProfileJBossServerComponent.createConfigurationBasedResource(ProfileJBossServerCompo
nent.java:235)
at org.rhq.plugins.jbossas5.ProfileJBossServerComponent.createResource(ProfileJBossServerComponent.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:623)
at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:450)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:713)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
... 18 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
17 years, 5 months
[JBoss JIRA] Created: (JBMESSAGING-1407) Add Bridgenames to log4j logging
by Markus Lutum (JIRA)
Add Bridgenames to log4j logging
--------------------------------
Key: JBMESSAGING-1407
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1407
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core
Affects Versions: 1.4.0.SP3
Reporter: Markus Lutum
Assignee: Tim Fox
Priority: Minor
Can you add the name of the Bridge while logging at the Bridge!
Specially while failure establishing connections or while successful reconnecting messages like:
"Succeeded in reconnecting to servers"
are not very helpful.
In our case at production we have 3 Bridges per node installed and a total of 3 Nodes.
So in summary 9 Bridges. It is very helpful to see which bridge failed and which was reconnected.
Thx
Markus
--
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, 5 months
[JBoss JIRA] Created: (JBMESSAGING-1013) Manual merge queue feature via JMX
by Evgueni Smoliar (JIRA)
Manual merge queue feature via JMX
----------------------------------
Key: JBMESSAGING-1013
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1013
Project: JBoss Messaging
Issue Type: Feature Request
Components: Configuration and Management, JMS Clustering
Environment: Clustering/load balancing
Reporter: Evgueni Smoliar
Assigned To: Tim Fox
In a case of disaster recovery you are obliged always to recover last running cluster node. Otherwise some messages will remain in the queue waiting for this node to startup. Idd there is a workaround for this, but it's not always easy to do. Would me much nicer to have a manual function to merge queues ( or reallocate messages) preferably available via JMX.
For more detail please check forum.
--
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
17 years, 5 months
[JBoss JIRA] Created: (JBRULES-1817) FactTemplateFieldExtractor must implement equals() method
by Stephanie Kroll (JIRA)
FactTemplateFieldExtractor must implement equals() method
---------------------------------------------------------
Key: JBRULES-1817
URL: https://jira.jboss.org/jira/browse/JBRULES-1817
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 4.0.7
Environment: Sun JDK1.5.0_12 on Windows XP
Reporter: Stephanie Kroll
Assignee: Mark Proctor
FactTemplateFieldExtractor does not implement equals(). This causes rules not to fire when the number of literal string equality constraints equals or exceeds the alpha node hashing threshold.
To reproduce for the trivial case, I created the following rule package:
package TestFactTemplate
template MyFact
String stringVal;
end
rule "Rule1"
when
MyFact (stringVal == "AA")
then
System.out.println("Rule1 fired");
end
rule "Rule2"
when
MyFact (stringVal == "AA")
then
System.out.println("Rule2 fired");
end
I implemented the Fact interface and returned "AA" from the two getFieldValue() methods. I also set the alphaNodeHashingThreshold to 2. When executing the rules, only Rule2 fires.
If FactTemplateFieldExtractor implements equals() like so:
public boolean equals(final Object object) {
if ( this == object ) {
return true;
}
if ( !(object instanceof FactTemplateFieldExtractor) ) {
return false;
}
final FactTemplateFieldExtractor other = (FactTemplateFieldExtractor) object;
return this.factTemplate.equals(other.factTemplate) &&
this.fieldIndex == other.fieldIndex;
}
then both rules fire.
The problem arises because without the equals() method for the field extractor, the LiteralConstraints do not report as equal, and the network does not reuse the nodes in BuildUtils.attachNode. When CompositeObjectSinkAdapter hashes the sinks because the threshold is met, only the last one is preserved in the hashedSinkMap since the HashKeys are the same.
--
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, 5 months
[JBoss JIRA] Created: (JBAS-5507) Internal IP Address Leak - JBoss Application Server
by Jeremy Carroll (JIRA)
Internal IP Address Leak - JBoss Application Server
---------------------------------------------------
Key: JBAS-5507
URL: http://jira.jboss.com/jira/browse/JBAS-5507
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Tested on Windows / Linux JBoss installations (4.0.3, 4.0.4, 4.2.2)
Reporter: Jeremy Carroll
When sending an HTTP 1.0 request that results in a 302 redirect, JBoss will leak the internal IP address of the server in the Location response. Basically you create a HTTP 1.0 request to a URL which will result in a 302. Then you can see in the internal server IP / name. I have mitigated this issue with a front end Web Application Firewall by denying HTTP 1.0 requests as a workaround. Is there a setting in tomcat or JBoss to not allow this to happen? It is pretty widespread from testing I have done in the lab. It results in a PCI compliance violation by scoring it as an exploit.
Example:
GET /application HTTP/1.0
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://arcenae:8090/application/
Date: Wed, 07 May 2008 03:10:36 GMT
Connection: close
--
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
17 years, 5 months
[JBoss JIRA] Created: (JBMESSAGING-1127) Use SSL certificate for client authentication
by Brendan Sibre (JIRA)
Use SSL certificate for client authentication
---------------------------------------------
Key: JBMESSAGING-1127
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1127
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Remoting, JMS Security
Affects Versions: 1.4.0.GA
Environment: JBAS 4.2.1 on Solaris 9 and 10, Sun JVM 1.5.0
Reporter: Brendan Sibre
Assigned To: Tim Fox
Clients connect to JBM using the sslbisocket connector. They should be able to use a client certificate to authenticate them via my custom loginmodule (which has been tested and works with EJBs, Tomcat, etc).
Use the principal created by the SSL connection for the getConnection() so that I do not need to pass a username and password. It seems that the callback handler used by the JBoss Messaging and the remoting SSLBisocket connector needs to be able to handle an X509Callback. This probably means that
it will need to be a HandshakeCompletedListener on the remoting connector.
Ideally, this method of authentication would be configured with the connector and then JBoss Messaging would use a CallerIdentityLoginModule to
accept the Subject that already exists so that JBoss Messaging will continue to work with EJBs (JmsXA) etc.
Forum posts include links to other potentially related JIRA issues. Hopefully JBoss Messaging can address this issue as it fits in the junction between
JBM and remoting.
--
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
17 years, 5 months