[JBoss JIRA] Created: (JBAS-3633) Tidyup logging when transaction is no longer active
by Adrian Brock (JIRA)
Tidyup logging when transaction is no longer active
---------------------------------------------------
Key: JBAS-3633
URL: http://jira.jboss.com/jira/browse/JBAS-3633
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: JB5-Transaction Manager
Affects Versions: JBossAS-4.0.5.CR1
Reporter: Adrian Brock
Priority: Minor
Since JBossTM rollsback transactions at transaction timeout,
we need to tidyup the transaction demarcation code (commit/rollback/setRollbackOnly, etc)
such that the logging is more information and not so noisy.
We still need to communicate that the transaction rolled back even if it is not
the transaction demarcation point that does the rollback.
Currrently, you get errors/warnings about not being able to setRollbackOnly or rollback,
because the transaction is already ended.
--
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, 8 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, 8 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, 8 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, 9 months