JBossDeveloper

"scott.stark@jboss.org" wrote:

In terms of updating the xml deployment layer, is this something that should wait for the schema driven version or are we keeping the BeanSchemaBinding around?

I see you added both?

http://anoncvs.forge.jboss.com/changelog/JBoss?cs=MAIN:starksm:20051105191252
http://anoncvs.forge.jboss.com/changelog/JBoss?cs=MAIN:starksm:20051106031544

One is used for the beaninfo, the other for the construction.
But only the bean level one (beaninfo) is tested.

Update:
I already changed it to:
* Use a ClassLoaderMetaData on the bean which is used everywhere
* Fix the "whenRequired" for classloader injection to be "DESCRIBED" see

ClassLoaderMetaData.visit()

"scott.stark@jboss.org" wrote:

1. improve the tests security configuration to get rid of the hard-coded security policy hacks that were added.

2. add the deployment level class loader info with another mock vfs class loader test.

AbstractKernelDependencyTest
 protected ControllerContext install(int number, String name) throws Throwable
 {
 if (xmltest)
 {
 deploy(number);
 return util.getContext(name);
 }
 else
 {
 return util.install(beanMetaDatas[number]);
 }
 }

"scott.stark@jboss.org" wrote:

3. look into nested deployments with different scoped class loaders to see how the ejb/war mismatch fits into the new MC. This gets back to another issue of class loader relationships. A war pojo talking to an ejb deployment needs its class loader to ignore the classes exported by the ejb to avoid the call by reference conflicts. The war class loader metadata needs to be augmented by the ejb class loader exports. This is going to require augmentation of the base metadata from the deployment via another aspect. What is the best way to do this via the current MC features?

I'm not sure if this is relevant? But just a heads up on "good design".

I expect a lot of the behavioural changes (that are not expressed through
annotations and their overrides) to be done through factory injection.

e.g. The new jca implementation allows different implementations of the timer
just based on an implementing a factory interface:

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"
 xmlns="urn:jboss:bean-deployer">

 <bean name="TimerFactory" class="org.jboss.jca.plugins.rar.timer.JDKTimerFactory"/>

 <bean name="BootstrapContextFactory" class="org.jboss.jca.spi.rar.BootstrapContextFactory">
 <property name="timerFactory"><inject bean="TimerFactory"/></property>
 </bean>

 <bean name="TestRAR" class="org.jboss.test.jca.rar.support.TestResourceAdapter">
 <start method="start">
 <parameter><inject bean="BootstrapContextFactory" property="bootstrapContext"/></parameter>
 </start>
 </bean>

</deployment>

"scott.stark@jboss.org" wrote:

"adrian@jboss.org" wrote:
Update:
I already changed it to:
* Use a ClassLoaderMetaData on the bean which is used everywhere
...

Ok, I need to understand the visitor pattern better. I'll go over these changes when their done.

"scott.stark@jboss.org" wrote:
The problem is that this is a non-trivial function of the pojo interaction between the two domains. A call-by-value interaction can leave the ejb interfaces/types as visible from a war class loader that is doing child first loading. A call-by-reference interaction cannot. So one implementation might have the factory look at all injections from the war to the ejb deployment to determine if there were call-by-reference uses. Alternatively, the processing of the injection metadata might have a vistor that updates the class loader metadata to do this and the factory simply uses the metadata it receives. I'm not clear on what factilities the MC offers to explore these alternatives.

OSGI solves this problem by having both a notion of export and import.
For the WAR case, the classloader (really module in OSGI) would both
export and import its ejb client classes.
i.e. I have these classes, but I'm happy to use somebody else's if they are compatible.

There is then an algorithm used to decide which of the EJB and WAR modules
actually serves as the exporter (with all classloading requests for those classes
going to the exporter's classloader).

The alogirthm is mainly based on who provides the most compatible version
of the classes. e.g. if the EJB exports V1.8 and the WAR exports V1.7 but is
happy to use V1.7+ then the EJB's classes will be used.

So this is really a deployment/module time thing
that requires something to keep track of dependencies.

Case 1:
Deploy EJB (classes at V1.8 but will use V1.8+)
Deploy WAR (classes at V.1.7 but will use V1.7+)
Ok will use WAR will use EJB classes

Case 2:
Deploy WAR (classes at V.1.7 but will use V1.7+)
Deploy EJB (classes at V1.8 but will use V1.8+)
Not OK. The WAR already started using V1.7 classes.

Solutions to Case2:
* Just fail
* Force a redeploy of the WAR to resolve the issue

If this belongs in the MC work, it is in the aspectized deployers or profile service plugins
which have a "WHAT DO I NEED TO DO?" notion and in the later case an "offline" mode.
Rather than the MC which just has a more direct "DO THIS" style metadata.