December 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Serialization] - Re: JBOSS Serialization & other JBOSS projects

by clebert.suconic＠jboss.com

JBoss Serialization is used on EJB3, and could be used on Remoting if you configure it so. Java Serialization still used on the Application Server in several places. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112432#4112432 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112432

18 years, 3 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by bstansberry＠jboss.com

JIRA -- that you immediately fix :). The values should be copied. Without them the Invocation API contract cannot be properly met (e.g. Invocation.getInvocationContext(), Invocation.getTransientValue()). Maybe those methods are never called (except, I guess, now they are called in your tests ;)) but they are part of the API and properly supporting the API is worth the cost of a couple of assignment operations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112409#4112409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112409

18 years, 3 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

In fact, JBAS-2436 is about making serialization of objects between proxy and invoker pluggable. This was not done in trunk or if it was done, was reverted. However, I think this is a different matter to my last comment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112394#4112394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112394

18 years, 3 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

Back once again (like the renegade master :)) trunk and 4.2.x differ slightly when it comes to org.jboss.invocation.MarshalledInvocation class. in 4.2.x, MarshalledInvocation(Invocation invocation) constructor does: ... this.transient_payload = invocation.transient_payload; this.invocationContext = invocation.invocationContext; ... whereas in trunk, the transient payload is not copied over to the MarshalledInvocation. The discrepancy comes from: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/branches/Branch_4_2/se... as part of: "JBAS-2436 - Commiting Pluggable Serialization into JBAS 4.0" (http://jira.jboss.com/jira/browse/JBAS-2436) Whether the transient payload is copied over to the MarshalledInvocation is not very important because eventually, writeExternal won't write it. However, why would you copy over a transient value over to an invocation that will be marshalled and which will not include transient values?? This discrepancy is making the tests that run in trunk not work in 4.2.x. I can workaround this but I don't think this type of discrepancies are good. Thoughts? Worth a JIRA? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112393#4112393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112393

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security access

by alesj

See revision 68200 for the 'live' example. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112387#4112387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112387

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Security access

by alesj

How is security enforced in our tests? Randomly? :-) I've introduced the code we were discussing here: - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=123834&start=10 --> wrapping the BeanInfo.set with MetaDataStack push, TCL change, PrivilegedAction execution if AccessControllerContext is present. When running ConfigTestSuite, I get all tests passing, except for all 3 ValueFactory(XML|Annotation)TestCase that fail due to security check in AbstractKernelControllerContext.getClassloader. What's the catch here, for all those tests that also execute that piece of code easily pass, but those three fail? | 3468 ERROR [AbstractKernelController] Error installing to Configured: name=PropHolder state=Instantiated | java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) | at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) | at java.security.AccessController.checkPermission(AccessController.java:427) | at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) | at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.getClassLoader(AbstractKernelControllerContext.java:244) | at org.jboss.kernel.plugins.dispatch.InvokeDispatchHelper.invoke(InvokeDispatchHelper.java:76) | at org.jboss.beans.metadata.plugins.AbstractValueFactoryMetaData.getValue(AbstractValueFactoryMetaData.java:293) | at org.jboss.beans.metadata.plugins.AbstractCollectionMetaData.getValue(AbstractCollectionMetaData.java:90) | at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:82) | at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper$1.run(PropertyDispatchWrapper.java:96) | at java.security.AccessController.doPrivileged(Native Method) | at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:52) | at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:108) | at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:108) | at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:88) | at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:45) | at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:135) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112356#4112356 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112356

18 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Missing feature in EJB2 ContainerConfiguration merge

by alex.loubyansky＠jboss.com

I fixed it. Would it be ok to make the fix version 5.0.0.Beta3? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112354#4112354 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112354

18 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Refactoring ServerPeer

by clebert.suconic＠jboss.com

Updating the JAR also require updating config files. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112336#4112336 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112336

18 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Refactoring ServerPeer

by timfox

"scott.stark(a)jboss.org" wrote : The issue patch has been updated to apply to the Branch_Stable code. There was an NPE in the all config that had been seen earlier when trying SP2 release. Its due to the hsqldb-persistence-service.xml/MessagingPostOfficeService/GroupMember being started before a view membership is received, and the latch being null. The patch has a check for this condition and a warning printed about being started before the view is seen. | Scott - can you tell me how to replicate this NPE? I'd like to investigate it further. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112322#4112322 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112322

18 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Refactoring ServerPeer

by scott.stark＠jboss.org

The issue patch has been updated to apply to the Branch_Stable code. There was an NPE in the all config that had been seen earlier when trying SP2 release. Its due to the hsqldb-persistence-service.xml/MessagingPostOfficeService/GroupMember being started before a view membership is received, and the latch being null. The patch has a check for this condition and a warning printed about being started before the view is seen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112319#4112319 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112319

18 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2007