[Design the new POJO MicroContainer] - Re: vfsmemory url problem
by alesj
"scott.stark(a)jboss.org" wrote : One of the appclient jbossas test regressions is due to the following error resulting from a vfs url of the form:
| vfsmemory://5c4o0b-m9hkak-fk2sx83e-1-fk2t2t85-1z/classes/
|
|
| | 2265 [main] WARN org.jboss.kernel.plugins.dependency.AbstractKernelController - Broken callback: ClassSingleCallbackItem@563a3d{name=class org.jboss.classloading.spi.dependency.Module whenRequired=ControllerState@7e33de{Configured} dependentState=ControllerState@7f4790{Installed} attributeName=addModule owner=AbstractKernelControllerContext@6f84d8{ metadata=AbstractBeanMetaData@5e8a8f{name=ClassLoading bean=org.jboss.classloading.spi.dependency.ClassLoading properties= constructor=null autowireCandidate=true installCallbacks=[method=addModule] uninstallCallbacks=[method=removeModule]}name=ClassLoading target=org.jboss.classloading.spi.dependency.ClassLoading@f6e3e9 state=Installed depends=AbstractDependencyInfo@335332{idependOn=[]}} signature=org.jboss.classloading.spi.dependency.Module}
| | java.lang.IllegalArgumentException: Root can not contain '/'
| | at org.jboss.virtual.plugins.context.memory.MemoryContextFactory.createRoot(MemoryContextFactory.java:108)
| | at org.jboss.virtual.plugins.context.memory.MemoryContextFactory.getVFS(MemoryContextFactory.java:76)
| | at org.jboss.virtual.VFS.getVFS(VFS.java:89)
| | at org.jboss.virtual.VFS.getRoot(VFS.java:103)
| | at org.jboss.classloading.spi.vfs.dependency.VFSClassLoaderPolicyModule.determineVFSRoots(VFSClassLoaderPolicyModule.java:170)
| | at org.jboss.classloading.spi.vfs.dependency.VFSClassLoaderPolicyModule.determineCapabilities(VFSClassLoaderPolicyModule.java:98)
| | at org.jboss.classloading.spi.dependency.Module.getCapabilities(Module.java:485)
| | at org.jboss.classloading.spi.dependency.Module.determinePackageNames(Module.java:544)
| | at org.jboss.classloading.spi.dependency.ClassLoadingSpace.join(ClassLoadingSpace.java:213)
| | at org.jboss.classloading.spi.dependency.Domain.addModule(Domain.java:151)
| | at org.jboss.classloading.spi.dependency.ClassLoading.addModule(ClassLoading.java:58)
| | 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.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
| | at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
| | at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
| | at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
| | at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:279)
| | at org.jboss.dependency.plugins.SingleCallbackItem.changeCallback(SingleCallbackItem.java:67)
| | at org.jboss.dependency.plugins.AbstractCallbackItem.changeCallback(AbstractCallbackItem.java:79)
| | at org.jboss.dependency.plugins.OwnerCallbackItem.changeCallback(OwnerCallbackItem.java:88)
| | at org.jboss.dependency.plugins.AbstractController.resolveCallbacks(AbstractController.java:1398)
| | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:908)
| | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1026)
| | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:948)
| | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:738)
| | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:506)
| | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:331)
| | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:309)
| | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
| | at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
| | at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88)
| | at org.jboss.ejb3.client.ClientLauncher.deploy(ClientLauncher.java:349)
| | at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:241)
| | at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:158)
| | at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:147)
| | at org.jboss.test.ee5client.unit.SimpleResourceUnitTestCase.testClientLauncher(SimpleResourceUnitTestCase.java:100)
| |
|
| The appclient is not creating this url, so I'm not sure where its coming from or why this is an invalid vfsmemory url.
|
Fixed. ;-)
| one-test:
| [delete] Deleting: C:\DOCUME~1\Ales\LOCALS~1\Temp\test.log
| [junit] Running org.jboss.test.ee5client.unit.SimpleResourceUnitTestCase
| [junit] 15:51:35,812 WARN [ClientLauncher] FIXME: using an unsupported hack to get metadata
| [junit] 15:51:38,359 WARN [ClientLauncher] sun.misc.Launcher$AppClassLoader@12498b5 != BaseClassLoader@fd1810{ClientLauncherClassPath:0.0.0$MODULE}
| [junit] 15:51:38,359 WARN [ClientLauncher] sun.misc.Launcher$AppClassLoader@12498b5 != BaseClassLoader@fd1810{ClientLauncherClassPath:0.0.0$MODULE}
| [junit] msg = Hello world
| [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3,922 sec
|
| BUILD SUCCESSFUL
|
Last deployers commit marked with JBDEPLOY-75
resolved the issue - I removed the 'classes' path,
leaving only guid host name.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171777#4171777
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171777
17 years, 7 months
[Design of EJB 3.0] - Re: EJBTHREE-1454 Encapsulate Container infomation in TO/VO
by ALRubinger
"jaikiran" wrote : + /**
| | + * Returns the initial context
| | + * @return
| | + */
| | + InitialContext getInitialContext();
Let's make that just return Context, otherwise, yup.
"jaikiran" wrote : 1) The interface InvokableContext sounds generic and probably can be used to carry out any generic invocation. So is it appropriate to introduce getGuid (and similar) method here? What i mean is, do all invocable objects need to have a Guid?
Keep in mind that everything here is implicitly pertaining to EJB3 Proxies, so I think all of the methods above are necessary for a contract between the EJB3 Container and the Proxy component (InvokableContext sounding more generic aside). So long as we're making sure that Proxy *needs* all this information, and we're not bleeding EJB3 Core internals outside, we're OK.
"jaikiran" wrote : 2) The following 2 methods are not available in the EJB3 Core SessionSpecContainers. ...
|
| String getName(); // Currently the EJB3 core, generates a name based on getObjectName().getCanonicalName()
getName() is inherited by way of EJBContainer...
"jaikiran" wrote : String getGuid(); // EJB3 Core, currently uses Ejb3Registry.guid(this) to generate this
True story. Even though the true state is held in Ejb3Registry, I suppose this could be considered an extended property of the container, so go ahead and expose a getGuid() there which delegates back to Ejb3Registry.
"jaikiran" wrote : 3) I see that the getAdvisor method is deprecated on the EJBContainer:
|
| | @Deprecated
| | public Advisor getAdvisor()
| | {
| | return beanContainer._getAdvisor();
| | }Any specific reason?
Yes, because the EJB Containers have been refactored a few too many times and we'd really like to tuck away the underlying Advisor, but really can't just now because too many outside components depend upon its exposure.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171681#4171681
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171681
17 years, 7 months