[JBoss JIRA] Created: (JBAS-3647) Backport SingleRetryInterceptor to 3.2
by Scott M Stark (JIRA)
Backport SingleRetryInterceptor to 3.2
--------------------------------------
Key: JBAS-3647
URL: http://jira.jboss.com/jira/browse/JBAS-3647
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering, EJB2
Affects Versions: JBossAS-3.2.8.SP1
Reporter: Scott M Stark
Assigned To: Brian Stansberry
A 3.2.8.SP1 client attempting to connect to a 4.0.4 clustered bean fails with the following error due to the SingleRetryInterceptor not being available in 3.2.8.SP1:
2006-09-12 16:44:30,178 [Thread-0::] - javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException:
org.jboss.proxy.ejb.SingleRetryInterceptor (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:318)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:143)
at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918)
We should backport 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
17 years, 3 months
[JBoss JIRA] Created: (JBCLUSTER-180) Calling getters/setters cluster wide - covenience feature
by Galder Zamarreno (JIRA)
Calling getters/setters cluster wide - covenience feature
---------------------------------------------------------
Key: JBCLUSTER-180
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-180
Project: JBoss Clustering
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Galder Zamarreno
Assigned To: Brian Stansberry
Priority: Optional
We'd like to check the values of an attirbute on all cluster nodes. Is there any quick way to do so?
During the startup of your own JMX MBean service you first have to register it with HAPartition
using registerRPCHandler method in HAPartition [1]. Provide a service name and your own
MBean object as parameters.
When checking a value of an attribute of your mbean in the whole cluster you would invoke
HAPartition.callMethodOnCluster together with service name parameter provided for
registerRPCHandler method. You have to expose this attribute as an operation
However, it would be more convenient to just use getter or setter. thanks,
--
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, 3 months
[JBoss JIRA] Created: (EJBTHREE-879) Injection metadata in ejb-jar.xml does not override @EJB annotation
by Justin (JIRA)
Injection metadata in ejb-jar.xml does not override @EJB annotation
-------------------------------------------------------------------
Key: EJBTHREE-879
URL: http://jira.jboss.com/jira/browse/EJBTHREE-879
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - Patch 1
Environment: OS-System: Linux 2.6.16.27-0.6-smp,i386
Java VM: Java HotSpot(TM) Server VM 1.6.0-b105,Sun Microsystems Inc.
JBoss [Zion] 4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)
JBoss EJB 3.0 RC9 Patch 1
Reporter: Justin
I have 2 stateless session EJBs, RecipientServiceBean and InjectedServiceBean.
RecipientService exposes a remote interface. InjectedService exposes only a local interface and is injected into the 'injectedService' field of the RecipientServiceBean
--------------------------------------------------- RecipientServiceBean ---------------------------------------------------
@Stateless(name="RecipientServiceBean")
@Remote(RecipientService.class)
public class RecipientServiceBean implements RecipientService {
@EJB(mappedName="overrideinjection/InjectedServiceBean/local")
private InjectedService injectedService;
public String saySomething() {
return "Hello: " + injectedService.getResponse();
}
}
--------------------------------------------------- InjectedServiceBean ---------------------------------------------------
@Stateless(name="InjectedServiceBean")
@Local(InjectedService.class)
public class InjectedServiceBean implements InjectedService {
public String getResponse() {
return "This is the real service";
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------------
I now want to override the injection specified by the @EJB annotation to inject a stub service. The stub service and ejb-jar.xml included is as follows
--------------------------------------------------- RecipientServiceStubBean ---------------------------------------------------
public class InjectedServiceStubBean implements InjectedService {
public String getResponse() {
return "THIS IS THE STUB";
}
}
--------------------------------------------------- ejb-jar.xml ---------------------------------------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
version="3.0">
<enterprise-beans>
<session>
<ejb-name>RecipientServiceBean</ejb-name>
<remote>com.sadalbari.test.overrideinjection.RecipientService</remote>
<ejb-class>com.sadalbari.test.overrideinjection.impl.RecipientServiceBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<ejb-local-ref>
<ejb-ref-name>ejb/InjectedService</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>com.sadalbari.test.overrideinjection.InjectedService</local>
<ejb-link>InjectedServiceStubBean</ejb-link>
<injection-target>
<injection-target-class>com.sadalbari.test.overrideinjection.impl.RecipientServiceBean</injection-target-class>
<injection-target-name>injectedService</injection-target-name>
</injection-target>
</ejb-local-ref>
</session>
<session>
<ejb-name>InjectedServiceStubBean</ejb-name>
<local>com.sadalbari.test.overrideinjection.InjectedService</local>
<ejb-class>com.sadalbari.test.overrideinjection.impl.InjectedServiceStubBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
---------------------------------------------------------------------------------------------------------------------------------------------------------
A dump of my JNDI view at this point
+- overrideinjection (class: org.jnp.interfaces.NamingContext)
| +- RecipientServiceBean (class: org.jnp.interfaces.NamingContext)
| | +- remote (proxy: $Proxy61 implements interface com.sadalbari.test.overrideinjection.RecipientService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBObject)
| +- InjectedServiceStubBean (class: org.jnp.interfaces.NamingContext)
| | +- local (proxy: $Proxy56 implements interface com.sadalbari.test.overrideinjection.InjectedService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject)
| +- InjectedServiceBean (class: org.jnp.interfaces.NamingContext)
| | +- local (proxy: $Proxy56 implements interface com.sadalbari.test.overrideinjection.InjectedService,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject)
---------------------------------------------------------------------------------------------------------------------------------------------------------
The result is that the injection is not overridden and the stub is not used in preference to the 'real service':
Hello: This is the real service
I can work around this issue by removing the @EJB annotation and ALWAYS declaring the injection in the ejb-jar.xml in which case I get:
Hello: THIS IS THE STUB
Thanks
Justin
--
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, 3 months
[JBoss JIRA] Created: (JBAS-3926) Move remoting transports out of conf/jboss-service.xml to a
by Scott M Stark (JIRA)
Move remoting transports out of
conf/jboss-service.xml to a remoting-beans.xml
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Move remoting transports out of conf/jboss-service.xml to a
Move remoting transports out of conf/jboss-service.xml to a remoting-beans.xml
-------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-3926
URL: http://jira.jboss.com/jira/browse/JBAS-3926
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Deployment services, Remoting
Reporter: Scott M Stark
Assigned To: Dimitris Andreadis
We need to remove remoting transports out of conf/jboss-service.xml to a remoting-beans.xml
--
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, 3 months
[JBoss JIRA] Created: (JBRULES-588) Improve documentation to provide guidance for large rulesets over 10K
by peter lin (JIRA)
Improve documentation to provide guidance for large rulesets over 10K
---------------------------------------------------------------------
Key: JBRULES-588
URL: http://jira.jboss.com/jira/browse/JBRULES-588
Project: JBoss Rules
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: Documentation
Reporter: peter lin
Assigned To: Mark Proctor
Priority: Trivial
Last week someone contacted me directly and asked whether JBossRules could handle 50K+ rules. I think it would be good to expand "5.1.8. Large drl files" of the documentation to provide some practical strategies and guidance to users. The docs already recommend increasing the permGen, but more guidance should be provided. Most users aren't going to know what to do when they really have to load 50K rules in the same appserver or jvm.
I will try to write something up and check it in this weekend. hopefully when my brain is marginally functional.
--
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, 3 months
[JBoss JIRA] Created: (JBAS-3570) SSLUnitTestCase testsuite failures when using the IBM JVM
by Matt Wringe (JIRA)
SSLUnitTestCase testsuite failures when using the IBM JVM
---------------------------------------------------------
Key: JBAS-3570
URL: http://jira.jboss.com/jira/browse/JBAS-3570
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.0.4.GA
Environment: IBM 1.4.2 JDK
RHEL 4, Linux Kernel 2.6.9
Arch: i386
Reporter: Matt Wringe
The org.jboss.test.web.test.ssl.SSLUnitTestCase tests fail when the IBM JDK is used.
testHttpRedirect
Error: Connection refused
testHttpRedirectSecurityDomain
Error: Connection refused
testHttps
Error: Connection refused
testHttpsSecurityDomain
Error: Connection refused
Stack Trace:
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:336)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:201)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:188)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.connect(Socket.java:428)
at java.net.Socket.<init>(Socket.java:335)
at java.net.Socket.<init>(Socket.java:150)
at com.ibm.jsse.bv.<init>(Unknown Source)
at com.ibm.jsse.JSSESocketFactory.createSocket(Unknown Source)
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:93)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:652)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:628)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497)
at org.jboss.test.web.test.ssl.SSLUnitTestCase.doHttps(SSLUnitTestCase.java:117)
at org.jboss.test.web.test.ssl.SSLUnitTestCase.testHttpsSecurityDomain(SSLUnitTestCase.java:85)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
--
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, 3 months