[JBoss JIRA] Created: (JBAS-4591) Create a generic way to createDestinations on MDB Container
by Clebert Suconic (JIRA)
Create a generic way to createDestinations on MDB Container
-----------------------------------------------------------
Key: JBAS-4591
URL: http://jira.jboss.com/jira/browse/JBAS-4591
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JB5-Messaging
Reporter: Clebert Suconic
Assigned To: Clebert Suconic
Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.4.0.CR1
We should provide a generic way to configure the MDB container to create destinations in other providers besidess JBossMQ.
The Implementation I'm going to do will use a Property Name for the MBean responsible to create destinations and method names for the create methods.
Also... we will support two signatures... one (createTopic(String Topicname) or createQueue(String queueName))
or
createTopic(String TopicName, String jndti) or createQueue(String queueName, String jndi)
--
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, 5 months
[JBoss JIRA] Created: (JASSIST-43) ConstPool.getItem(int) returns unexpected item, causes exceptions in calling methods; e.g. in getFieldrefClassName(...) and getInterfaceMethodrefClassName(...)
by Martin Burger (JIRA)
ConstPool.getItem(int) returns unexpected item, causes exceptions in calling methods; e.g. in getFieldrefClassName(...) and getInterfaceMethodrefClassName(...)
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JASSIST-43
URL: http://jira.jboss.com/jira/browse/JASSIST-43
Project: Javassist
Issue Type: Bug
Environment: $ uname -a
Darwin [...] 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
$ java -version
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
Javassist 3.6.0
Reporter: Martin Burger
Assigned To: Shigeru Chiba
I am using subclasses of javassist.expr.ExprEditor to heavily instrument classes. On some large (in terms of amount of code) classes I get various exceptions in ConstPool, for example:
Caused by: java.lang.ClassCastException: javassist.bytecode.ClassInfo
at javassist.bytecode.ConstPool.getFieldrefClassName(ConstPool.java:254)
at javassist.expr.FieldAccess.getClassName(FieldAccess.java:97)
at javassist.expr.FieldAccess.getCtClass(FieldAccess.java:89)
at javassist.expr.FieldAccess.getField(FieldAccess.java:112)
And:
Caused by: java.lang.NullPointerException
at javassist.bytecode.ConstPool.getInterfaceMethodrefClassName(ConstPool.java:413)
at javassist.expr.MethodCall.getClassName(MethodCall.java:91)
at javassist.expr.MethodCall.getCtClass(MethodCall.java:75)
at javassist.expr.MethodCall.getMethod(MethodCall.java:114)
It seems that ConstPool.getItem(int) returns an "unexpected" item, so (1) the cast to FieldrefInfo fails and (2) the returned item is null instead of an instance of InterfaceMethodrefInfo, respectively.
--
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, 5 months
[JBoss JIRA] Created: (EJBTHREE-1260) Performance issue with EjbLinkDemandMetaData
by Guy Coleman (JIRA)
Performance issue with EjbLinkDemandMetaData
--------------------------------------------
Key: EJBTHREE-1260
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1260
Project: EJB 3.0
Issue Type: Bug
Components: core
Affects Versions: AS 5.0.0.Beta4
Reporter: Guy Coleman
We have an application with about 200 EJB3 SLSB and MDBs, 120 EJB2 entity beans and a few web apps.
This takes about 1-2 minutes to start up with JBoss 4.2.2.GA. With 5.0.0.Beta4 this jumps to around 20-30 minutes. Some thread dumps show that it's spending most of its time here:
"main" prio=6 tid=0x044b7430 nid=0x10b4 runnable [0x049cd000..0x049cf9f8]
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.<init>(Throwable.java:196)
at java.lang.Exception.<init>(Exception.java:41)
at javax.management.JMException.<init>(JMException.java:35)
at javax.management.OperationsException.<init>(OperationsException.java:36)
at javax.management.MalformedObjectNameException.<init>(MalformedObjectNameException.java:35)
at javax.management.ObjectName.construct(ObjectName.java:393)
at javax.management.ObjectName.<init>(ObjectName.java:1304)
at org.jboss.ejb3.dependency.EjbLinkDemandMetaData$EjbLinkDemandDependencyItem.resolve(EjbLinkDemandMetaData.java:134)
at org.jboss.dependency.plugins.AbstractDependencyInfo.resolveDependencies(AbstractDependencyInfo.java:140)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:901)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:839)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
at org.jboss.system.ServiceController.doChange(ServiceController.java:659)
at org.jboss.system.ServiceController.create(ServiceController.java:393)
at org.jboss.system.ServiceController.create(ServiceController.java:358)
at sun.reflect.GeneratedMethodAccessor212.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:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
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:668)
at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:186)
Patching EjbLinkDemandMetaData to avoid creating ObjectNames for names that are obviously invalid speed this up considerably: the startup time is then about 5 minutes, though It still seems to spend a lot of time looping in that EjbLinkDemandDependencyItem .resolve
--
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, 5 months
[JBoss JIRA] Created: (JBPORTAL-1392) WSRP does not submit the from when enctype set to "multipart/form-data"
by Andrey Adamovich (JIRA)
WSRP does not submit the from when enctype set to "multipart/form-data"
-----------------------------------------------------------------------
Key: JBPORTAL-1392
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1392
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal WSRP
Affects Versions: 2.6.CR2
Environment: All
Reporter: Andrey Adamovich
Assigned To: Chris Laprun
We are developing a portlet on BEA WebLogic Portal that is supposed to be consumed later by JBoss Portal. This portlet is used for file data upload. The thing is that portlet contains a form that has enctype attribute set to multipart/form-data to enable file sending. When the form is submitted on the consumer (JBoss) no form parameters are passed to producer. Looking in the WSRP request sent to BEA Portal by JBoss only action name is seen. If enctype attribute is removed from the form then when form is submitted all parameters are sent to producer except file content.
--
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, 6 months
[JBoss JIRA] Created: (JASSIST-42) Proxy serialization looses inner data objects
by Damien Lecan (JIRA)
Proxy serialization looses inner data objects
---------------------------------------------
Key: JASSIST-42
URL: http://jira.jboss.com/jira/browse/JASSIST-42
Project: Javassist
Issue Type: Bug
Reporter: Damien Lecan
Assigned To: Shigeru Chiba
Priority: Blocker
I working with proxies build with ProxyFactory method.
When I want to serialize/deserialize it, everything seems to be ok except that only proxy instance is serialized, not inner objects.
Eg.
Object "A" contains an instance of "B"
After serialization/deserialization of a proxy of A, instance of "B" in "A" is null
When I look at this code :
public static SerializedProxy makeSerializedProxy(Object proxy)
throws java.io.InvalidClassException
{
Class clazz = proxy.getClass();
return new SerializedProxy(clazz, ProxyFactory.getFilter(clazz),
ProxyFactory.getHandler(clazz));
}
I don't understand how serialization can keep inner objects ...
--
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, 6 months
[JBoss JIRA] Created: (JBAS-4344) Problematic casting to String in org.jboss.jmx.connector.invoker.AuthenticationInterceptor
by David Dossot (JIRA)
Problematic casting to String in org.jboss.jmx.connector.invoker.AuthenticationInterceptor
------------------------------------------------------------------------------------------
Key: JBAS-4344
URL: http://jira.jboss.com/jira/browse/JBAS-4344
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: JBossAS-4.0.4.GA
Environment: Mac Os X, RedHat
Reporter: David Dossot
Assigned To: Dimitris Andreadis
There is a problematic cast in org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(Invocation invocation) on line 110:
String opname = (String) obj[1];
When Twiddling to get a particular attribute, the following code is used in org.jboss.console.twiddle.command.GetCommand.execute(String[] args) on line 165:
attributeNames.toArray(names);
(...)
AttributeList attrList = server.getAttributes(objectName, names);
So obj[1] ends up holding a String[] of attribute names (even if there is only one) and the cast fails:
14:14:44,760 ERROR [Twiddle] Exec failed
java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String
at org.jboss.jmx.connector.invoker.AuthorizationInterceptor.invoke(AuthorizationInterceptor.java:107)
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.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:589)
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:819)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
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:589)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:679)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:704)
at java.lang.Thread.run(Thread.java:637)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:331)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:194)
at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy0.getAttributes(Unknown Source)
at org.jboss.console.twiddle.command.GetCommand.execute(GetCommand.java:168)
at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:305)
--
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, 6 months
[JBoss JIRA] Created: (JBAS-4383) Allow a different JSF implementation to be packaged in the WAR
by Stan Silvert (JIRA)
Allow a different JSF implementation to be packaged in the WAR
--------------------------------------------------------------
Key: JBAS-4383
URL: http://jira.jboss.com/jira/browse/JBAS-4383
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JavaServerFaces
Affects Versions: JBossAS-4.2.0.CR2, JBossAS-5.0.0.Beta2
Reporter: Stan Silvert
Assigned To: Stan Silvert
Fix For: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta3, JBossAS-5.0.0.GA
Prior to JEE5, most developers would bundle a JSF implementation such as MyFaces with the WAR. With AS 4.2 and 5.0, you should instead rely on the JSF implementation that ships with the container.
However, for these legacy applications that rely on a particular implementation, we can disable the built-in JSF implementation as long as you stick with the default classloader settings. To disable the built-in JSF, you will add this to your web.xml:
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
--
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, 6 months
