August 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Serialization] - Re: Mustang Serialization problems.

by clebert.suconic＠jboss.com

The stack trace you sent is JavaSerialization. (see.... at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128) ) package names for JBossSerialization are starting with org.jboss.serial.... You would need to configure your remoting layer to use JBossSerialization if you want to test this with JBoss Serialization. I know that there are a couple of issues with JBossRemoting when using Mustang with regular Java Serialization. Tom Elrod (Project lead for JBoss Remoting) is working on it. Something about some change with ClassLoading operations on Mustang: http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.6/... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964686#3964686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964686

19 years, 8 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Heavy Refactoring of parameter syncing and ParameterMeta

by jason.greene＠jboss.com

Ok I will reply once I commit everything. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964683#3964683 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964683

19 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Tomcat java compiler ignores annotations

by bill.burke＠jboss.com

The java compiler that compiles JSPs that comes with Tomcat does not insert annotation information into the .class bytes. This means that if you use @EJB, or whatever in your USP, the field/method it is annotated to will not have the annotation embedded in bytecode. Thus any annotation processor will fail. I haven't tried the old ANT way of doing this stuff yes, but we may have to revert to that. Should I reenable the ant stuff if it does the appropriate annotation compilation? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964680#3964680 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964680

19 years, 8 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Intiatial annotation support

by bill.burke＠jboss.com

Ok, I've implemented annotatin support for tomcat with a small test in ejb3 module under: org/jboss/ejb3/test/dd/web/servlet/EJBServlet.java I haven't tested any XML stuff beyond basic EJB-refs. This means the injeciton-target, etc... I'll get to that on Monday. JSP injeciton is not supported yet. The hooks aren't in the current Tomcat codebase, but are easy enough to add. The problem is that the java compiler for JSPs does not insert annotaiton information. I'll start a new thread for this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964678#3964678 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964678

19 years, 8 months

1
0
0 / 0

[Design of JBoss Serialization] - Mustang Serialization problems.

by thammoud

Hello, We have encountered a serialization problem when we moved to JDK 1.6. The following EJB throws an exception (Below). public class TestServiceBean implements TestService { @TransactionAttribute(TransactionAttributeType.REQUIRED) public Format getFormat() { return DateFormat.getDateInstance(DateFormat.SHORT); } } The code works perfectly in 1.5. We tried the latest nightly build of Mustang to no avail. Peforming a deep clone to the same object locally works fine thus leading us to believe that the interaction with JBOSS is what is causing this problem. We are using 4.0.4 JA on linux. Thanks for any info. Caused by: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.io.StreamCorruptedException: invalid type code: 00 at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:306) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102) ... 2 more Caused by: java.io.StreamCorruptedException: invalid type code: 00 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1356) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1642) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945) at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:480) at java.util.Calendar.readObject(Calendar.java:2609) 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:597) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1846) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:107) at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66) at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964666#3964666 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964666

19 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: First real SARDeployer porting issue

by scott.stark＠jboss.org

The next issue is that the thread context class loader seen in the mbean invocations as in this stack: | Thread [VFSDeploymentScanner] | InvocationContext.loadClass(String) line: 317 | InvocationContext.getReturnTypeClass() line: 198 | Invocation.getReturnTypeClass() line: 121 | ModelMBeanOperationInterceptor.invoke(Invocation) line: 65 | Invocation.invoke() line: 90 | XMBean(AbstractMBeanInvoker).invoke(String, Object[], String[]) line: 264 | MBeanServerImpl.invoke(ObjectName, String, Object[], String[]) line: 668 | ServiceCreator.installPlainMBean(MBeanServer, ObjectName, ServiceMetaData) line: 199 | ServiceCreator.install(MBeanServer, ObjectName, ServiceMetaData, Object) line: 111 | InstantiateAction.installAction(ServiceControllerContext) line: 45 | InstantiateAction(ServiceControllerContextAction).install(ControllerContext) line: 46 | ServiceControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51 | ServiceControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 226 | ServiceControllerContext.install(ControllerState, ControllerState) line: 187 | AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 596 | AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 346 | AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 438 | AbstractKernelController(AbstractController).resolveContexts(boolean) line: 379 | AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 263 | AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 164 | ServiceController.install(Element, ObjectName) line: 228 | SARDeployer.deploy(DeploymentContext) line: 309 | DeploymentGraphVisitor.visit(Graph<DeploymentContext>, Vertex<DeploymentContext>) line: 74 | Graph<T>.depthFirstSearch(Vertex<T>, VisitorEX<T,E>) line: 225 | MainDeployerImpl.deploy(Deployment) line: 321 | VFSDeploymentScannerImpl.deploy(VirtualFile) line: 608 | VFSDeploymentScannerImpl.scan() line: 520 | VFSDeploymentScannerImpl.run() line: 376 | Executors$RunnableAdapter<T>.call() line: 417 | FutureTask$Sync.innerRunAndReset() line: 280 | ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(FutureTask<V>).runAndReset() line: 135 | ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$101(ScheduledThreadPoolExecutor$ScheduledFutureTask) line: 65 | ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.runPeriodic() line: 142 | ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run() line: 166 | ThreadPoolExecutor$Worker.runTask(Runnable) line: 650 | ThreadPoolExecutor$Worker.run() line: 675 | Thread.run() line: not available | is neither the bean nor SARDeployer class loader. Its the server core org.jboss.system.server.NoAnnotationURLClassLoader, which does not have the jmx classes in the current setup. These are only visible via the JMXClassLoader instance associated with the JMXKernel and SARDeployer beans. The VFSClassLoader is not a valid ClassLoadingDomain/DomainClassLoader that can support a unified typesystem currently. This is something I'm going to work on next week while I"m on vacation. What I want to do for now is punt and put the jmx class back into the core server loader class loader and spend a couple of hours cleaning up as many SARDeployer issues as I can, and then document the curent state of the VDF impl in the MC_VDF_WORK branch so some progress on porting deployer can be done next week while I'm out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964657#3964657 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964657

19 years, 8 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Ordering of .ear subdeployments

by scott.stark＠jboss.org

The ordering solution needs to be complete, so the jboss-appl.xml needs to have an explicit ordering section that allows a unified ordering of both the application.xml and jboss-app.xml deployments. In the point release we should also be able to disable the change in ordering behavior to avoid breaking existing deployments like the test-cif.ear. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964655#3964655 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964655

19 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Stress/Load Testing plan/suggestions

by julien＠jboss.com

Good point Danny, and the CMS portlet depends on jackrabbit too So any test of that kind should use custom portlets that does not rely on a backend to test the performances of the portal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964651#3964651 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964651

19 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Getting class type matching beans from KernelController

by adrian＠jboss.org

The code should be similar to demand/supply You need to maintain a cross reference map in the controller from the InstallAction. | Map<Class, Object> beansByClass; | Then you need to augment the injection dependency to resolve against this map (when no name is given). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964650#3964650 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964650

19 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Getting class type matching beans from KernelController

by alesj

What's the easies (proper) way to get all beans from KernelController (or any other Kernel managed object) which are instance of certain class? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964648#3964648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964648

19 years, 8 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 August 2006