[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
When setting up my schema resolver
| private TestSchemaResolver setupResolver()
| {
| TestSchemaResolver resolver = new TestSchemaResolver();
|
|
| SchemaBinding binding1 = addSchemaBinding(resolver, AbstractKernelDeployment.class);
| SchemaBinding binding2 = addSchemaBinding(resolver, AOPDeployment.class);
| SchemaBinding binding3 = addSchemaBinding(resolver, AspectBeanMetaDataFactory.class);
| SchemaBinding binding4 = addSchemaBinding(resolver, JavaBean.class);
|
| return resolver;
| }
|
| private SchemaBinding addSchemaBinding(TestSchemaResolver resolver, Class<?> clazz)
| {
| SchemaBinding binding = JBossXBBuilder.build(clazz);
| resolver.addSchemaBinding(binding);
| return binding;
| }
|
the AspectBeanMetaDataFactory replaces the AOPDeployment, which is obvious having looked at the TestSchemaResolver. For AbstractKernelDeployment, all the associated metadata classes are added. My guess is that this is because they are referenced somehow by the AbstractKernelDeployment. If I have understood the previous posts correctly, the AOPDeployment should be kept simple, i.e.:
| @JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED)
| @XmlRootElement(name="aop")
| @XmlType(propOrder={"annotations", "classLoader", "beanFactories", "create", "start", "stop", "destroy", "aliases"})
| public class AOPDeployment extends AbstractKernelDeployment
| {
| private static final long serialVersionUID = 1L;
| }
|
The question is how do I get metadata classes such as AspectBeanMetaDataFactory, into the same SchemaBinding as AOPDeployment (into binding2)?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131174#4131174
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131174
18 years, 1 month
[Design of JBoss ESB] - Re: COM Gateway
by DirkBangel
Hi Mark and Kurt,
Thanks for your replies and recommendations. In the last couple of day, we investigated the Web services with COM approach. Unfortunately we found out that it is an invasive procedure(changes on the server) and requires a lot of setup. And is as you mentioned performance intensive. One of the reasons why we chose j-Interop for communication with COM was that it is completely non invasive . It is a pure java library implementing COM binary protocol, and its performance is acceptable to us. We are building a SAAS platform where we see a lot of potential for an ESB (currently we need to support SAP R/3). I apologise I cannot go much into details due to IP reason.
As for point 1 by Kurt:-
Sorry about the misunderstanding of "Listener", but from my point of understanding the notifier is only a special kind of action which listens on a channel.
[service]
[listeners/]
[actions]
[action/] <----
[/actions]
[/service]
May be we used an invalid naming? Please correct me if I am wrong.
We will start the initial analysis and architecture of our gateway/bridge. Is it possible for us to post the papers here for review ?
Thanks,
best regards,
Dirk
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131170#4131170
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131170
18 years, 1 month
[Design the new POJO MicroContainer] - State of the Microcontainer
by adrian＠jboss.org
INTRODUCTION:
I'm down to three tasks on the classloading before I start integrating it into the appserver.
* The management features
* The subdeployment level classloader
* The dyanmic import stuff for OSGi
There's a couple of other things I want to get done, such as:
1) Fixing the hack that currently allows AOP to takeover the constructor joinpoint
of the MC
2) Something I discussed with Alex such that schema bindings and their use
can be in one file. But Alex is on holiday until next Tuesday.
i.e. this is so you can do
| <deployment xmlns:jbossxb="urn:jboss:xml:2.0"
| jbossxb:schemaclasses="urn:whatever com.acme.SomeClass"
| <whatever xmlns='urn:whatever"/>
|
Currently you have to preconfigure the schema resolver in a different file
to make the wildcard (or not defined in factory settings) schemas work.
This issue first came up with trying to define the @JMX attribute in
bootstrap-beans.xml which was impossible because the aop namespace
wasn't configured and there was no previous configuration file
in which to define it. ;-)
QUESTION:
So it looks like I'll be integrating it all (and testing) next week.
I need to know whether there is anything funny or incomplete in the current MC codebase
and that nobody's going to do a major piece of work (or breakage ;-) during this period?
I know we didn't do an release for Beta4 because things weren't ready,
so I except to find a few funnies.
Speak now....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131166#4131166
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131166
18 years, 1 month
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
"kabir.khan(a)jboss.com" wrote : I am getting the following error when trying to set up the SchemaResolver
|
| | java.lang.RuntimeException: No such property for bean org.jboss.beans.info.spi.EventInfo available []
| | at org.jboss.beans.info.spi.EventInfo.
| | at org.jboss.beans.info.spi.BeanInfo.events
| | at org.jboss.kernel.spi.dependency.KernelControllerContext.beanInfo
| | at org.jboss.aop.microcontainer.beans.beanmetadatafactory.AOPDeployment.installedContexts
| | at org.jboss.aop.microcontainer.beans.beanmetadatafactory.AOPDeployment
| | at org.jboss.xb.builder.JBossXBNoSchemaBuilder.rethrowWithLocation(JBossXBNoSchemaBuilder.java:1854)
| | at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:285)
| | at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElements(JBossXBNoSchemaBuilder.java:260)
| | at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:184)
| | at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:102)
| | at org.jboss.aop.microcontainer.junit.JAXBDeployer.addSchemaBinding(JAXBDeployer.java:105)
| |
|
Adding the same @XMLType as AbstractKernelDeployment fixes it
| @JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED)
| @XmlRootElement(name="aop")
| @XmlType(propOrder={"annotations", "classLoader", "beanFactories", "create", "start", "stop", "destroy", "aliases"})
| public class AOPDeployment extends AbstractKernelDeployment
| {
| private static final long serialVersionUID = 1L;
| }
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131159#4131159
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131159
18 years, 1 month
[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use
by adrian＠jboss.org
I'm going to use this thread to complete the description of all the classloader metadata
in one place.
RE-EXPORTS
Beyond what is mentioned above, a reqiurement can take a reExport attribute.
This allows you to build up "super modules" for ease of use, e.g.
| <classloader xmlns="urn:jboss:classloader:1.0">
| <capabilities>
| <module name="javaee" version="1.5"/>
| </capabiltiies>
| <requirements>
| <module name="javax.jms" version="1.1" reExport="true"/>
| <module name="javax.ejb" version='3.0" reExport="true/>
| etc.
|
Then somebody can do the following to get the entire javaee api.
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <module name="javaee" version="1.5"/>
| </requirements>
| </classloading>
|
NOTE: This is only works for module requirements. Other types of requirements
like individual packages don't pick up re-exports.
OPTIONAL
You can specify that a requirement is optional, e.g.
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <module name="foo" optional="true"/>
| </requirements>
| </classloading>
|
If the module "foo" exists it will be imported, otherwise the requirement will be ignored.
USES
This is similar to optional, where you can specify that you want
to use somebody else's export of a package if it is exists, but otherwise
you will use your own version (included in your classpath).
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <uses name="com.acme.blah"/>
| </requirements>
| </classloading>
|
EXPLICIT VERSION
A requirement can take an explicit version constraint
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <module name="com.acme.blah" version="1.0.0"/>
| </requirements>
| </classloading>
|
In mathematical language :
1.0.0 <= version <= 1.0.0
FROM VERSION
You can specify a from version which is inclusive by default
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <module name="com.acme.blah" from="1.0.0"/>
| </requirements>
| </classloading>
|
1.0.0 <= version
or not inclusive
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <module name="com.acme.blah" from="1.0.0" from-inclusive="false"/>
| </requirements>
| </classloading>
|
1.0.0 < version
TO VERSION
You can specify a to version which is exclusive by default
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <module name="com.acme.blah" to="1.0.0"/>
| </requirements>
| </classloading>
|
version < 1.0.0
or inclusive
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <module name="com.acme.blah" to="1.0.0" to-inclusive="true"/>
| </requirements>
| </classloading>
|
version <= 1.0.0
CONTEXT NAME
In the classloader namespace that is used by the -beans.xml
you'd use it something like this;
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
| <classloader><inject bean="MyClassLoader:1.0.0"/></classloader>
| <classloader xmlns="urn:jboss:classloader:1.0" name="MyClassLoader" version="1.0.0">
|
NOTE, by default the context name in the MC is name:version.
But you can override this if you don't like it, e.g.
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
| <classloader><inject bean="Fred"/></classloader>
| <classloader xmlns="urn:jboss:classloader:1.0" name="MyClassLoader" version="1.0.0" context="Fred">
|
It's just a name after all ;-)
The deployment version, just uses the deployment controller context name.
CLASSLOADERSYSTEM
By default, the classloader (-beans.xml usage) will get registered in a ClassLoaderSystem
called .... "ClassLoaderSystem" :-)
But you can change it.
| <classloader xmlns="urn:jboss:classloader:1.0" name="MyClassLoader" version="1.0.0" system="SomethingElse">
|
I doubt anybody would want to change it, since you'd have to change
it consistently across all classloaders that want to export/import each other.
For the deployment processing, the ClassLoaderSystem is injected
into the deployer configuration.
DONE
I think that's about it? If I find I missed something, I'll add it here.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131152#4131152
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131152
18 years, 1 month
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
I am getting the following error when trying to set up the SchemaResolver
| java.lang.RuntimeException: No such property for bean org.jboss.beans.info.spi.EventInfo available []
| at org.jboss.beans.info.spi.EventInfo.
| at org.jboss.beans.info.spi.BeanInfo.events
| at org.jboss.kernel.spi.dependency.KernelControllerContext.beanInfo
| at org.jboss.aop.microcontainer.beans.beanmetadatafactory.AOPDeployment.installedContexts
| at org.jboss.aop.microcontainer.beans.beanmetadatafactory.AOPDeployment
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.rethrowWithLocation(JBossXBNoSchemaBuilder.java:1854)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:285)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElements(JBossXBNoSchemaBuilder.java:260)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:184)
| at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:102)
| at org.jboss.aop.microcontainer.junit.JAXBDeployer.addSchemaBinding(JAXBDeployer.java:105)
| at org.jboss.aop.microcontainer.junit.JAXBDeployer.setupResolver(JAXBDeployer.java:96)
| at org.jboss.aop.microcontainer.junit.JAXBDeployer.unmarshal(JAXBDeployer.java:82)
| at org.jboss.aop.microcontainer.junit.AOPMicrocontainerTestDelegate.unmarshal(AOPMicrocontainerTestDelegate.java:138)
| at org.jboss.aop.microcontainer.junit.ForceJAXBAOPMicrocontainerTest.unmarshal(ForceJAXBAOPMicrocontainerTest.java:50)
| at org.jboss.test.microcontainer.beans.test.JAXBAnnotationSanityTestCase.unmarshal(JAXBAnnotationSanityTestCase.java:178)
| at org.jboss.test.microcontainer.beans.test.JAXBAnnotationSanityTestCase.testAspectWithDefaultNameAndScope(JAXBAnnotationSanityTestCase.java:62)
| 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 junit.framework.TestCase.runTest(TestCase.java:154)
| at junit.framework.TestCase.runBare(TestCase.java:127)
| at junit.framework.TestResult$1.protect(TestResult.java:106)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.framework.TestResult.run(TestResult.java:109)
| at junit.framework.TestCase.run(TestCase.java:118)
| at junit.framework.TestSuite.runTest(TestSuite.java:208)
| at junit.framework.TestSuite.run(TestSuite.java:203)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
| at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
| at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
| Caused by: java.lang.IllegalArgumentException: No such property for bean org.jboss.beans.info.spi.EventInfo available []
| at org.jboss.beans.info.plugins.AbstractBeanInfo.getProperty(AbstractBeanInfo.java:160)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1053)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:695)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:683)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:462)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:421)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1715)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1054)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:695)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:683)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:462)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:421)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1715)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1054)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:695)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:683)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:462)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:421)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1715)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1054)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:695)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:683)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:462)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:421)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createElementBinding(JBossXBNoSchemaBuilder.java:300)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:280)
| ... 32 more
|
|
| public KernelDeployment unmarshal(final URL url) throws Exception
| {
| TestSchemaResolver resolver = setupResolver();
|
| KernelDeployment deployment = (KernelDeployment)jbossXbTestDelegate.unmarshal(url.toString(), resolver);
|
| deployment.setName(url.toString());
|
| return deployment;
| }
|
| private TestSchemaResolver setupResolver()
| {
| TestSchemaResolver resolver = new TestSchemaResolver();
|
| addSchemaBinding(resolver, AbstractKernelDeployment.class);
| addSchemaBinding(resolver, AOPDeployment.class); //Error happens here
| ...
|
| return resolver;
| }
|
| private SchemaBinding addSchemaBinding(TestSchemaResolver resolver, Class<?> clazz)
| {
| SchemaBinding binding = JBossXBBuilder.build(clazz);
| resolver.addSchemaBinding(binding);
| return binding;
| }
|
Where
| @JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED)
| //(a)JBossXmlSchema(elementFormDefault=XmlNsForm.UNQUALIFIED)
| @XmlRootElement(name="aop")
| public class AOPDeployment extends AbstractKernelDeployment
| {
| private static final long serialVersionUID = 1L;
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131144#4131144
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131144
18 years, 1 month