Generated Classes not found if they do not matc...| JBoss.org Content Archive (Read Only)

30. Re: Generated Classes not found if they do not match any of

kabirkhan Mar 11, 2009 7:23 AM (in response to kabirkhan)

Edited my last 2 posts

31. Re: Generated Classes not found if they do not match any of

aloubyansky Mar 11, 2009 9:35 AM (in response to kabirkhan)

So, valueObject is bound to a wildcard and {urn:jboss:classloading:1.0}capabilities should be resolved as its content. Perhaps, it cannot be.
Can you enable TRACE for org.jboss.xb?

32. Re: Generated Classes not found if they do not match any of

kabirkhan Mar 11, 2009 11:31 AM (in response to kabirkhan)

I have committed what has been done so far in trunk against https://jira.jboss.org/jira/browse/JBCL-92

For the time being I have commented out the capabilities stuff in GeneratedClassesUnitTestCase.xml, and hardcoded them in my MockGlobalCapabilitiesProvider.

33. Re: Generated Classes not found if they do not match any of

kabirkhan Mar 11, 2009 12:00 PM (in response to kabirkhan)

"kabir.khan@jboss.com" wrote:
I then noticed that 'capabilities' is spelt wrong in CapabilitiesMetaData:
@XmlType(name="capabilties", propOrder= {"capabilities"})
public class CapabilitiesMetaData implements Serializable, Cloneable

I created a JIRA issue for this https://jira.jboss.org/jira/browse/JBCL-93. Simple fix, but I don't want to break anything

34. Re: Generated Classes not found if they do not match any of

kabirkhan Mar 11, 2009 12:27 PM (in response to kabirkhan)

"alex.loubyansky@jboss.com" wrote:
So, valueObject is bound to a wildcard and {urn:jboss:classloading:1.0}capabilities should be resolved as its content. Perhaps, it cannot be.
Can you enable TRACE for org.jboss.xb?

The trace was too long, but Ales suggested offline I add @XmlRootElement to CapabilitiesMetaData.

@XmlType(name="capabilties", propOrder= {"capabilities"})
@XmlRootElement(name="capabilities", namespace="urn:jboss:classloading:1.0")
public class CapabilitiesMetaData implements Serializable, Cloneable

This now works, and as per Adrian's previous suggestion I added a helper bean to jboss-cl

public class DefaultGlobalCapabilitiesProvider implements GlobalCapabilitiesProvider
{
 List<Capability> capabilities;

 public void setGlobalCapabilities(CapabilitiesMetaData capabilitiesMetaData)
 {
 capabilities = capabilitiesMetaData.getCapabilities();
 }

 public List<Capability> getCapabilities()
 {
 return capabilities;
 }
}

Usage in GeneratedClassesUnitTestCase.xml

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">

 <bean name="DefaultGlobalCapabilitiesProvider" class="org.jboss.classloading.plugins.dependency.DefaultGlobalCapabilitiesProvider">
 <property name="globalCapabilities">
 <capabilities xmlns="urn:jboss:classloading:1.0">
 <package name="newpackage"/>
 </capabilities>
 </property>
 </bean>

</deployment>

The tests so far use importAll=true for the classloaders. Now, I'm going to try to break this where the requesting classloader has explicit imports

35. Re: Generated Classes not found if they do not match any of

kabirkhan Mar 11, 2009 1:29 PM (in response to kabirkhan)

Here is the first problem, when running with importAll=false

 public void testExplicitImportGenerateClassInExistingPackage() throws Exception
 {
 runExplicitImportGenerateClass(EXISTING_PACKAGE, true);
 }

 private void runExplicitImportGenerateClass(GeneratedClassInfo info, boolean expectSuccess) throws Exception
 {
 ClassLoadingMetaDataFactory factory = ClassLoadingMetaDataFactory.getInstance();
 String dynamicClassRoot = getDynamicClassRoot();
 VFSClassLoaderFactory a = new VFSClassLoaderFactory("a");
 a.getRoots().add(getRoot(A.class));
 a.getCapabilities().addCapability(factory.createPackage(A.class.getPackage().getName()));
 KernelDeployment depA = install(a);

 VFSClassLoaderFactory b = new VFSClassLoaderFactory("b");
 b.getRoots().add(getRoot(B.class));
 b.getRoots().add(dynamicClassRoot);
 b.getCapabilities().addCapability(factory.createPackage(B.class.getPackage().getName()));
 b.getRequirements().addRequirement(factory.createRequirePackage(A.class.getPackage().getName()));
 KernelDeployment depB = install(b);

 ...
 }

When deploying this, I get the following error

1218 ERROR [AbstractKernelController] Error resolving dependencies for Installed: name=b:0.0.0$MODULE state=Start
java.lang.IllegalStateException: VFSClassLoaderPolicyModule b:0.0.0 cannot be added because it is exports package newpackage which conflicts
 with VFSClassLoaderPolicyModule a:0.0.0
 at org.jboss.classloading.spi.dependency.ClassLoadingSpace.join(ClassLoadingSpace.java:223)
 at org.jboss.classloading.spi.dependency.ClassLoadingSpace.joinAndResolve(ClassLoadingSpace.java:120)
 at org.jboss.classloading.spi.dependency.ClassLoadingSpace.joinAndResolve(ClassLoadingSpace.java:169)
 at org.jboss.classloading.spi.dependency.ClassLoadingSpace.resolve(ClassLoadingSpace.java:326)
 at org.jboss.classloading.spi.dependency.Module.resolveModule(Module.java:909)
 at org.jboss.classloading.spi.dependency.RequirementDependencyItem.resolve(RequirementDependencyItem.java:91)
 at org.jboss.dependency.plugins.AbstractDependencyInfo.resolveDependencies(AbstractDependencyInfo.java:138)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1103)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1039)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
 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.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:358)
 at org.jboss.test.kernel.junit.MicrocontainerTest.deploy(MicrocontainerTest.java:368)
 at org.jboss.test.classloading.vfs.metadata.VFSClassLoadingMicrocontainerTest.install(VFSClassLoadingMicrocontainerTest.java:208)
 at org.jboss.test.classloading.vfs.metadata.test.GeneratedClassesUnitTestCase.runExplicitImportGenerateClass(GeneratedClassesUnitTestCase.j
ava:171)
 at org.jboss.test.classloading.vfs.metadata.test.GeneratedClassesUnitTestCase.testExplicitImportGenerateClassInExistingPackage(GeneratedCla
ssesUnitTestCase.java:88)
 ...

I was not really expecting problems at this stage, I was writing this test to investigate if we would need a GlobalRequirementsProvider. The package "newpackage", mentioned in the trace, is one of the global capabilities. Can really 2 loaders with importAll=false not export the same package, or have I done something wrong?

36. Re: Generated Classes not found if they do not match any of

alesj Mar 12, 2009 7:32 AM (in response to kabirkhan)

"kabir.khan@jboss.com" wrote:
"alex.loubyansky@jboss.com" wrote:
So, valueObject is bound to a wildcard and {urn:jboss:classloading:1.0}capabilities should be resolved as its content. Perhaps, it cannot be.
Can you enable TRACE for org.jboss.xb?

The trace was too long, but Ales suggested offline I add @XmlRootElement to CapabilitiesMetaData.
@XmlType(name="capabilties", propOrder= {"capabilities"})
@XmlRootElement(name="capabilities", namespace="urn:jboss:classloading:1.0")
public class CapabilitiesMetaData implements Serializable, Cloneable

I guess you need to update the jboss-classloading-1.0.xsd as well. ;-)

37. Re: Generated Classes not found if they do not match any of

kabirkhan Mar 13, 2009 7:01 AM (in response to kabirkhan)

"alesj" wrote:

I guess you need to update the jboss-classloading-1.0.xsd as well. ;-)

It already has capabilites as a top-level complex type, or do I also need it as a top-level element?

$svn diff
Index: jboss-classloading-1.0.xsd
===================================================================
--- jboss-classloading-1.0.xsd (revision 85694)
+++ jboss-classloading-1.0.xsd (working copy)
@@ -25,6 +25,16 @@
 </xsd:annotation>
 </xsd:element>

+ <xsd:element name="capabilities" type="capabilities">
+ <xsd:annotation>
+ <xsd:documentation>
+ <![CDATA[
+ The capabilities for use in other schemas
+ ]]>
+ </xsd:documentation>
+ </xsd:annotation>
+ </xsd:element>
+
 <xsd:complexType name="classloadingType">
 <xsd:annotation>
 <xsd:documentation>

38. Re: Generated Classes not found if they do not match any of

alesj Mar 13, 2009 7:29 AM (in response to kabirkhan)

I'm no xsd expert :-), but I think you need it yes.
At least that's how some other complex types are also exposed.

39. Re: Generated Classes not found if they do not match any of

adrian.brock Mar 16, 2009 10:24 AM (in response to kabirkhan)

"kabir.khan@jboss.com" wrote:
"alex.loubyansky@jboss.com" wrote:
So, valueObject is bound to a wildcard and {urn:jboss:classloading:1.0}capabilities should be resolved as its content. Perhaps, it cannot be.
Can you enable TRACE for org.jboss.xb?

The trace was too long, but Ales suggested offline I add @XmlRootElement to CapabilitiesMetaData.
@XmlType(name="capabilties", propOrder= {"capabilities"})
@XmlRootElement(name="capabilities", namespace="urn:jboss:classloading:1.0")
public class CapabilitiesMetaData implements Serializable, Cloneable

Yes, for JBossXB to resolve the XmlAnyElement you need to define the top
level elment for "capabilities".

But you shouldn't include the namespace, otherwise it won't version properly
when we reuse the class in urn:jboss-classloading:2.0

You also need to define it in the xsd for xml validation.

40. Re: Generated Classes not found if they do not match any of

adrian.brock Mar 16, 2009 10:27 AM (in response to kabirkhan)

"kabir.khan@jboss.com" wrote:

I was not really expecting problems at this stage, I was writing this test to investigate if we would need a GlobalRequirementsProvider. The package "newpackage", mentioned in the trace, is one of the global capabilities. Can really 2 loaders with importAll=false not export the same package, or have I done something wrong?

This is currently an open problem in the classloading consistency checking:
https://jira.jboss.org/jira/browse/JBCL-25

41. Re: Generated Classes not found if they do not match any of

kabirkhan Mar 16, 2009 12:15 PM (in response to kabirkhan)

"adrian@jboss.org" wrote:

This is currently an open problem in the classloading consistency checking:
https://jira.jboss.org/jira/browse/JBCL-25

Regarding this

"JIRA Issue" wrote:

Eventually this must also include some kind of "package fragment' notion like OSGi
where the packages end up in the same physical classloader.

I don't think that is what we are after in this case, rather the aop generated proxies package should actually live in each separate classloader. On the other hand, I am experimenting with something which might remove the need for the initial requirement I had so stay tuned

42. Re: Generated Classes not found if they do not match any of

adrian.brock Mar 16, 2009 12:43 PM (in response to kabirkhan)

"kabir.khan@jboss.com" wrote:
"adrian@jboss.org" wrote:

This is currently an open problem in the classloading consistency checking:
https://jira.jboss.org/jira/browse/JBCL-25

Regarding this
"JIRA Issue" wrote:

Eventually this must also include some kind of "package fragment' notion like OSGi
where the packages end up in the same physical classloader.

I don't think that is what we are after in this case, rather the aop generated proxies package should actually live in each separate classloader

Yes, split packages (the same package in different deployments/classloaders)
and bundle/package fragments (adding classes/resources to existing classloaders)
are different capabilities,

The classloading should handle both use cases, it currently handles neither
with importAll=false and you link the classloaders because the validation doesn't understand it.