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

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

This is probably what Adrian said earlier in that other thread, but basically when I am putting the AspectManager into the MDR that is in the main controllers MDR. Similarly, PreInstallAction uses that repository for the context's ScopeInfo. However, in DescibeAction we use the following to obtain the repository | KernelMetaDataRepository repository = controller.getKernel().getMetaDataRepository(); | Beans deployed to the scoped controller get a different MDR from the main one, and there is no link between the two. Is adding a link possible so that there is a notion of a parent MDR? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169278#4169278 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169278

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by manik.surtani＠jboss.com

Scott is right, this does apply to JBC as well. Currently what I do is I have a concept of cache regions, and users register class loaders per region. Any calls that are then sent over the wire contain the following: [version id: short][region id: serialized Fqn][payload] my unmarshalling code currently: 1. reads the version id and delegates to the appropriate unmarshaller 2. unmarshaller reads the region id and sets the TCL appropriate to that region 3. continues unmarshalling payload, etc Pretty much like what Scott said. So looking at your APIs, I would need to be able to do something like: | marshallerFactory.setStreamHeader(new VersionHeader(versionId)); | marshallerFactory.setStreamHeader(new RegionHeader(myRegion)); | Marshaller m = marshallerFactory.createMarshalleroutput(); | and when unmarshalling, StreamHeaders should also be able to react to headers being present such that: | marshallerFactory.setStreamHeader(new VersionUnmarshallHeader()); | marshallerFactory.setStreamHeader(new RegionUnmarshallHeader()); | Unmarshaller m = marshallerFactory.createUnmarshallerInput(); | such that VersionUnmarshallHeader can read the version short and set the appropriate ObjectMarshallerFactory and ClassMarshallerFactory pertaining to the version of the protocol, and the RegionUnmarshallHeader would read the Region Fqn and set the TCL as needed. Perhaps the same StreamHeader impl could be used for both purposes - makes logical sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169269#4169269 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169269

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: MDB.getActivationConfigProperties handling of no destina

by adrian＠jboss.org

https://jira.jboss.org/jira/browse/JBAS-5841 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169263#4169263 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169263

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: MDB.getActivationConfigProperties handling of no destina

by adrian＠jboss.org

This patch is wrong. It should be constructing the InitialContext from the JMSProviderAdapterJNDI activation config property when using JBoss's jms rar. In the event of a thirdparty jms rar, you've got no clue what to do. If there is both a local jms and a remote jms (or a thirdparty jms) you could actually get the wrong result if the destination exists locally of a different type to the one that should be used in the remote or thirdparty jms. The correct place for this patch is org.jboss.resource.adapter.jms.inflow.JmsActivation, i.e. rework how setUpDestination() does things and remove the reliance on JmsActivationSpec.isTopic() from setUpConnection() Coupled with removal of destiantionType as a mandatory activation config property from the ra.xml View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169261#4169261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169261

17 years, 8 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Problem with JBoss Profiler 2 Beta install.

by jesper.pedersen

You need the full path to jboss-profiler.properties in your -D option. The jboss-profiler.properties inside the jar will be default values so you need to override them in your local copy. The client depends on other jar files like the jboss-remoting.jar. You need the files in the same directory as the client.jar. Otherwise see the MANIFEST.MF file inside client.jar for the needed jar files. You only need the jboss-profiler.jar and jboss-profiler-plugins.jar in AS/bin -- and asm.jar if you use the asm option inside the property file. Hope this helps ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169245#4169245 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169245

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by scott.stark＠jboss.org

It would seem to me that I can have the same cross domain marshalling problem in JBC itself as well though. If I have two applications sharing a cache across web apps in the same server, with different class loading domains for the shared data, it would have to be marshalled/unmarshalled in each web apps class loader space. In general marshalling/unmarshalling is going to need the ability to establish a class loader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169198#4169198 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169198

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Which is the best place to write a test case for ejb3-te

by ALRubinger

"jaikiran" wrote : I think i got an answer to this question. The SessionContainer infact is part of the proxy. So the testcase too can go there. I don't know why, so far, i have been thinking that the problem was in the ejb3-test module :) (probably the package org.jboss.ejb3.test confused me). Looks like it. That SessionContainer is a mock container which is part of EJB3 Proxy (as Proxy knows nothing about the *real* containers in EJB3 Core). So SessionContainer there just implements InvokableContext.invoke(), and has its own handling. Go ahead and create an issue, commit the testcase for it, and try for a fix on the SessionContainer in proxy tests. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169196#4169196 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169196

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Which is the best place to write a test case for ejb3-te

by jaikiran

Hmmm.... Just re-looked at the stacktrace: at org.jboss.ejb3.test.proxy.common.container.SessionContainer.invoke(SessionContainer.java:188) anonymous wrote : I'm actually trying to figure out the best place for the following testcase I think i got an answer to this question. The SessionContainer infact is part of the proxy. So the testcase too can go there. I don't know why, so far, i have been thinking that the problem was in the ejb3-test module :) (probably the package org.jboss.ejb3.test confused me). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169194#4169194 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169194

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Which is the best place to write a test case for ejb3-te

by jaikiran

"ALRubinger" wrote : | Nope. ;) | | EJB3 Test is a set of common test scaffolding/utilities that my be shared by the other components (think of it as EJB3 Common, but for testing dependencies only). | | So if you draw a dependency upon EJB3 Proxy to EJB3 Test, there will be a cyclic dependency. | That's what i wanted to understand :) Thanks. "ALRubinger" wrote : | What exactly are you trying to do? | I'm actually trying to figure out the best place for the following testcase. Here's more details (actually we had discussed this sometime back through a mail, but at that time, i never got to the point of coming up with a reproducible testcase): | public interface MySLSBLocal | { | void printObject(Object obj); | | } | @Stateless | @Local (MySLSBLocal.class) | public class MySLSBean implements MySLSBLocal | { | | public void printObject(Object obj) | { | System.out.println("Printing " + obj); | | } | | } And this is the testcase: | ..... | import org.jboss.ejb3.test.proxy.common.Utils; | import org.jboss.ejb3.test.proxy.common.container.SessionContainer; | ..... | | @Test | public void testBeanMethodInvocation() throws Throwable | { | // create the SLSB container | this.sessionContainer = Utils.createSlsb(MySLSBean.class); | | // bind to JNDI | Ejb3RegistrarLocator.locateRegistrar().bind(sessionContainer.getName(), sessionContainer); | | Context ctx = new InitialContext(); | // lookup the local bean | MySLSBLocal local = (MySLSBLocal) ctx.lookup(getDefaultBusinessLocalJndiName(sessionContainer)); | | assertNotNull("Local bean is null",local); | | //call the method | String someString = new String("I am some string"); | local.printObject(someString); | | } This fails with: | java.lang.reflect.UndeclaredThrowableException | at $Proxy55.printObject(Unknown Source) | at org.jboss.ejb3.test.proxy.jndiregistrar.unit.JndiSessionRegistrarBaseTestCase.testBeanMethodInvocation(JndiSessionRegistrarBaseTestCase.java:498) | 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.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) | at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) | at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) | at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) | at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) | at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) | at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) | at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) | at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) | at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) | at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) | at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) | at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) | at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) | at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165) | at org.apache.maven.surefire.Surefire.run(Surefire.java:107) | 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289) | at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993) | Caused by: java.lang.NoSuchMethodException: org.jboss.ejb3.test.proxy.jndiregistrar.MySLSBLocal.printObject(java.lang.String) | at java.lang.Class.getDeclaredMethod(Class.java:1909) | at org.jboss.ejb3.test.proxy.common.container.SessionContainer.invoke(SessionContainer.java:188) | at org.jboss.ejb3.proxy.handler.session.SessionSpecProxyInvocationHandlerBase.invoke(SessionSpecProxyInvocationHandlerBase.java:120) | ... 28 more | The root cause is that i have a method in the bean with accepts a base class param (java.lang.Object) where as i am invoking the bean method by passing it a child class (java.lang.String). The issue is that the java reflection API used in SessionContainer.invoke looks for a exact match for the Method. The reflection APIs do not support a way to find the best match for a Method. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169192#4169192 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169192

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting unmarshalling vs. class loaders

by scott.stark＠jboss.org

The remoting invocation handler is the only place where the correct class loader is known. The response object it returns is the only thing that can hold the class loader unless the handler itself is queried for this info. It could be hidden in an marshaller associated with the reply so its not an explicit part of the api, but having a marshaller being capable of knowing a handler specific class loader is what would be needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169191#4169191 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169191

17 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 2008