[JBoss JIRA] Commented: (JBAS-1955) XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions
by Magesh Kumar B (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1955?page=comments#action_12358787 ]
Magesh Kumar B commented on JBAS-1955:
--------------------------------------
Ok My bad,
As as Dimitris says, the name suggests that it only strips the MBeanInfo. I should have discussed it in the forum first. Thanks for taking care!
> XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions
> -----------------------------------------------------------------------------------
>
> Key: JBAS-1955
> URL: http://jira.jboss.com/jira/browse/JBAS-1955
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.2 Final
> Environment: jmx, twiddle
> Reporter: Fabiano C. de Oliveira
> Assigned To: Dimitris Andreadis
> Fix For: JBossAS-4.0.5.SP1 , JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2
>
> Attachments: JBAS-1955a.zip
>
> Time Spent: 3 days, 3 hours
> Remaining Estimate: 0 minutes
>
> This patch add a Interceptor to org.jboss.jmx.connector.invoker.InvokerAdaptorService besides AuthenticationInterceptor that is responsable for prevent remote clients to launch NonSerializable exception.
> The interception have 3 types of action: Invisible, Null and Wrapper.
> In the Invisible mode all NonSerializable fields are ignored so if you call getMBeanInfo all NonSerializable will be remove and returned to your remote client(twiddle, MC4J, etc). This mode is more tested so it is recommended.
> In the null mode NonSerializable fields are visible but always return Null.
> The wraper mode is not implemented, but the idea is replace the NonSerializable Class for another
> The interceptor is only a class. The tests are in the patch too. Only test for invisible mode. I´m still doing tests for the other modes.
> Any idea is very appreciated. I dont have sufficient time to work more in this code. But I hope to do soon.
--
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
19 years, 3 months
[JBoss JIRA] Closed: (JBAS-1955) XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1955?page=all ]
Dimitris Andreadis closed JBAS-1955.
------------------------------------
Resolution: Done
Assignee: Dimitris Andreadis (was: Magesh Kumar B)
I did the rollback.
> XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions
> -----------------------------------------------------------------------------------
>
> Key: JBAS-1955
> URL: http://jira.jboss.com/jira/browse/JBAS-1955
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.2 Final
> Environment: jmx, twiddle
> Reporter: Fabiano C. de Oliveira
> Assigned To: Dimitris Andreadis
> Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.GA, JBossAS-4.0.5.SP1
>
> Attachments: JBAS-1955a.zip
>
> Time Spent: 3 days, 3 hours
> Remaining Estimate: 0 minutes
>
> This patch add a Interceptor to org.jboss.jmx.connector.invoker.InvokerAdaptorService besides AuthenticationInterceptor that is responsable for prevent remote clients to launch NonSerializable exception.
> The interception have 3 types of action: Invisible, Null and Wrapper.
> In the Invisible mode all NonSerializable fields are ignored so if you call getMBeanInfo all NonSerializable will be remove and returned to your remote client(twiddle, MC4J, etc). This mode is more tested so it is recommended.
> In the null mode NonSerializable fields are visible but always return Null.
> The wraper mode is not implemented, but the idea is replace the NonSerializable Class for another
> The interceptor is only a class. The tests are in the patch too. Only test for invisible mode. I´m still doing tests for the other modes.
> Any idea is very appreciated. I dont have sufficient time to work more in this code. But I hope to do soon.
--
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
19 years, 3 months
[JBoss JIRA] Reopened: (JBAS-1955) XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1955?page=all ]
Dimitris Andreadis reopened JBAS-1955:
--------------------------------------
Magesh, I don't agree with your changes. If you read through my comments you'll see I only wanted to deal with the transfer of the MBeanInfo, not the getAttributes call.
And even if I wanted to deal with getAttributes I would do so by creating a new policy, not the changing StripModleMBeanInfoPolicy that does what it's name says.
We are also very close to a code freeze state, so no new features at this point.
Please rollback (and keep a local copy of) your changes. We'll reconsider them for a later release, after discussing the issue in the forums.
> XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions
> -----------------------------------------------------------------------------------
>
> Key: JBAS-1955
> URL: http://jira.jboss.com/jira/browse/JBAS-1955
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.2 Final
> Environment: jmx, twiddle
> Reporter: Fabiano C. de Oliveira
> Assigned To: Magesh Kumar B
> Fix For: JBossAS-4.0.5.SP1 , JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2
>
> Attachments: JBAS-1955a.zip
>
> Time Spent: 3 days, 3 hours
> Remaining Estimate: 0 minutes
>
> This patch add a Interceptor to org.jboss.jmx.connector.invoker.InvokerAdaptorService besides AuthenticationInterceptor that is responsable for prevent remote clients to launch NonSerializable exception.
> The interception have 3 types of action: Invisible, Null and Wrapper.
> In the Invisible mode all NonSerializable fields are ignored so if you call getMBeanInfo all NonSerializable will be remove and returned to your remote client(twiddle, MC4J, etc). This mode is more tested so it is recommended.
> In the null mode NonSerializable fields are visible but always return Null.
> The wraper mode is not implemented, but the idea is replace the NonSerializable Class for another
> The interceptor is only a class. The tests are in the patch too. Only test for invisible mode. I´m still doing tests for the other modes.
> Any idea is very appreciated. I dont have sufficient time to work more in this code. But I hope to do soon.
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBPORTAL-1332) Redeploy of FSContentDrivenPortlet fails
by Julien Viet (JIRA)
Redeploy of FSContentDrivenPortlet fails
----------------------------------------
Key: JBPORTAL-1332
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1332
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.6.Beta1
Reporter: Julien Viet
Assigned To: Thomas Heute
Fix For: 2.6.CR1
The mbean does not unregister properly which cause a redeploy of portal-samples.sar to fail :
01:02:38,962 WARN [ContentTypeRegistration] Couldn't perform ContentProvider registration
javax.management.InstanceAlreadyExistsException: portal:service=ContentRenderer,type=FSContentDrivenPortletInstance already registered.
at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:761)
at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:225)
at sun.reflect.GeneratedMethodAccessor1.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 org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
at org.jboss.portlet.content.ContentTypeRegistration.contextInitialized(ContentTypeRegistration.java:114)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3763)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4211)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBPORTAL-1317) Role Management Portlet: Create New Role Broken
by Bernard Tison (JIRA)
Role Management Portlet: Create New Role Broken
-----------------------------------------------
Key: JBPORTAL-1317
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1317
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.6.Alpha2
Environment: Portal 2.6 trunk on JBoss AS 4.0.5
Fedora FC6, Firefox Browser 1.5
Reporter: Bernard Tison
Assigned To: Julien Viet
The create new role link in the role management portlet is broken.
The link calls a javascript function. This javascript is defined in the jboss-portlet.xml of the portlet.
<portlet>
<portlet-name>RolePortlet</portlet-name>
<transaction>
<trans-attribute>Required</trans-attribute>
</transaction>
<header-content>
<script type="text/javascript" language="javascript">
function hideShow(id)
{
var navpoint = document.getElementById(id);
if (navpoint.className == 'hidden') {
navpoint.className = 'shown';
} else {
navpoint.className = 'hidden';
}
}
</script>
</header-content>
</portlet>
This javascript does not get injected into the rendered HTML. The resulting HTML fragment looks like:
<!-- insert header content that was possibly set by portlets on the page -->
<script type="text/javascript"></script>
I also tested this with the sample HeaderContentPortlet. I defined the following fragment in the jboss-portlet.xml of the HeaderContentPortlet:
<header-content>
<link rel="stylesheet" type="text/css" href="/portlet-styles/HeaderContent.css" media="screen"/>
<script type="text/javascript" language="javascript">
function hideShow(id)
{
var navpoint = document.getElementById(id);
if (navpoint.className == 'hidden') {
navpoint.className = 'shown';
} else {
navpoint.className = 'hidden';
}
}
</script>
<meta name="description" content="test"/>
</header-content>
The resulting HTML:
<!-- insert header content that was possibly set by portlets on the page -->
<link type="text/css" rel="stylesheet" href="/portal-samples/portlet-styles/HeaderContent.css" media="screen"/>
<script type="text/javascript"></script>
<meta name="description" content="test"/>
Wrapping the javascript function in a CDATA element did not solve the problem.
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBPM-945) Miss MailAction hibernate mapping file!
by David Chan (JIRA)
Miss MailAction hibernate mapping file!
---------------------------------------
Key: JBPM-945
URL: http://jira.jboss.com/jira/browse/JBPM-945
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Environment: Windows XP SP2
Java JDK 1.5.0_10
Eclipse 3.2.1
Reporter: David Chan
Assigned To: Tom Baeyens
A process definition contains a node with type 'mail' like below:
<?xml version="1.0" encoding="UTF-8"?>
<process-definition
xmlns="urn:jbpm.org:jpdl-3.2" name="mail">
<start-state name="start">
<transition name="a" to="task1">
<mail name="starter" actors="ws" subject="TT" text="NN"></mail>
</transition>
</start-state>
<end-state name="end1"></end-state>
<task-node name="task1">
<task name="task1"></task>
<transition name="b" to="end1"></transition>
</task-node>
</process-definition>
when I use JBPMContext to store the definition into DB, an exception will be thrown:
aused by: org.hibernate.HibernateException: instance not of expected entity type: org.jbpm.graph.action.MailAction is not a: org.jbpm.graph.def.Action
It's very clear that Hibernate can't know how to persist the class 'org.jbpm.graph.action.MailAction', in other words, there's no mapping file against to this class. So I created this file 'MailAction.hbm.xml', the content is very simple:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping default-access="field">
<subclass name="org.jbpm.graph.action.MailAction" extends="org.jbpm.graph.def.Action" discriminator-value="M"/>
</hibernate-mapping>
modify the Hibernate configuration file and add the file path as a mapping entry.
.....
<mapping resource="org/jbpm/graph/action/MailAction.hbm.xml"/>
.....
now run the process again, there's no problem!
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBPORTAL-1333) Executing ContentCreateNewVersionCommand causes NullPointerException
by Chunyun Zhao (JIRA)
Executing ContentCreateNewVersionCommand causes NullPointerException
--------------------------------------------------------------------
Key: JBPORTAL-1333
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1333
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal CMS
Affects Versions: 2.6.Beta1
Environment: Fedora Linux, JBoss-4.0.5.GA, JBoss Portal 2.6 Beta1
Reporter: Chunyun Zhao
Assigned To: Sohil Shah
Following is the code in my application that fails with NullPointerException:
Command cmd = repository.getCommandFactory().createContentCreateNewVersionCommand(cnt, true);
repository.execute(cmd);
Here is the stacktrace:
java.lang.NullPointerException
at java.util.StringTokenizer.<init>(StringTokenizer.java:182)
at java.util.StringTokenizer.<init>(StringTokenizer.java:204)
at org.jboss.portal.cms.impl.jcr.command.ACLEnforcer.computeAccess(ACLEnforcer.java:361)
at org.jboss.portal.cms.impl.jcr.command.ACLEnforcer.hasWriteAccess(ACLEnforcer.java:266)
at org.jboss.portal.cms.impl.jcr.command.ACLEnforcer.hasAccess(ACLEnforcer.java:126)
at org.jboss.portal.cms.security.AuthorizationManagerImpl.checkPermission(AuthorizationManagerImpl.java:127)
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: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 org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy45.checkPermission(Unknown Source)
at org.jboss.portal.cms.impl.interceptors.ACLInterceptor.invoke(ACLInterceptor.java:190)
at org.jboss.portal.cms.CMSInterceptor.invoke(CMSInterceptor.java:36)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:115)
at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:157)
at org.jboss.portal.cms.impl.jcr.JCRCMS.execute(JCRCMS.java:593)
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: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 org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy493.execute(Unknown Source)
at com.vec.ContentManagementServiceBean.createFile(ContentManagementServiceBean.java:135)
at com.vec.ContentManagementServiceBean.store(ContentManagementServiceBean.java:95)
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:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at net.taylor.trace.TraceInterceptor.invoke(TraceInterceptor.java:59)
at sun.reflect.GeneratedMethodAccessor275.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
... 318 more
After I dig into the source code, I believe the problem is with the hasWriteAccess and computeAccess methods of ACLEnforcer class. Basically when the command is ContentCreateNewVersionCommand, hasWriteAccess calls computeAccess with a null path which is then causing the NullPointerException.
-Chunyun Zhao
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-3724) NotFoundInDispatcherException from InvokerLocator when accessing remote calls when on a non default port
by Grant Quimby (JIRA)
NotFoundInDispatcherException from InvokerLocator when accessing remote calls when on a non default port
--------------------------------------------------------------------------------------------------------
Key: JBAS-3724
URL: http://jira.jboss.com/jira/browse/JBAS-3724
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services, EJB3, Remoting
Affects Versions: JBossAS-4.0.4.GA
Environment: One JBoss 4.0.4.GA install with two instances, one on the default ports and one on ports with an increase of 1000 on all port numbers.
Reporter: Grant Quimby
Assigned To: Dimitris Andreadis
Priority: Blocker
When trying to access a remote application that is running in a server instance that does not have the default InvokerLocator port (3873) the remote caller recieves a NotFoundInDispatcherException when trying to call a method in the EJB3 Stateless Session Bean as the EJB3 Session Bean's InvokerLocator is at port 4873 and not port 3873 where the Remote Proxy looks.
Similar issue for Service Beans at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89537
This is okay presently but in approximately two weeks we need to be running four instances with Session beans in two of them, which is currently not possible in a production version.
--
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
19 years, 3 months