Deployment lazyResolve and lazyStart

[adrian.brock]

With https://jira.jboss.org/jira/browse/JBDEPLOY-247

You can now do lazyResolve and lazyStart for deployments.

However, beyond what OSGi will do there's nothing that actually sets this up.

I propose we add a new META-INF/jboss-deployment.xml which would be some generic

metadata for this kind of processing and other possible deployment control parameters.

e.g. something like

<deployment xmlns="urn:jboss:deployment:1.0">

    <!-- Deploy this deployment in the described stage initially - i.e. no classloader -->

    <required-stage>DESCRIBE</required-stage>

    <!-- Only create the classloader when somebody wants to import our package or module -->

    <lazy-resolve/>

    <!-- Only move the deployment to the REAL stage when somebody loads a class from our classloader - with an optional filter -->

    <lazy-start filter="com.acme.somepackage"/>

</deployment>

[alesj]

    <!-- Only create the classloader when somebody wants to import our package or module -->

    <lazy-resolve/>

    <!-- Only move the deployment to the REAL stage when somebody loads a class from our classloader - with an optional filter -->

    <lazy-start filter="com.acme.somepackage"/>    

What's the difference between these two?
1st would only move to CLASSLOADER, where the 2nd would move to REAL?

[adrian.brock]

alesj wrote:

    <!-- Only create the classloader when somebody wants to import our package or module -->

    <lazy-resolve/>

    <!-- Only move the deployment to the REAL stage when somebody loads a class from our classloader - with an optional filter -->

    <lazy-start filter="com.acme.somepackage"/>    

What's the difference between these two?
1st would only move to CLASSLOADER, where the 2nd would move to REAL?

Yes.

[alesj]

1st would only move to CLASSLOADER, where the 2nd would move to REAL?

Yes.

What happens if there is no filter?

Every package is a trigger for REAL?

Or, what happens if you try to load a class past the filter?

[adrian.brock]

alesj wrote:

1st would only move to CLASSLOADER, where the 2nd would move to REAL?

Yes.

What happens if there is no filter?

Every package is a trigger for REAL?

Or, what happens if you try to load a class past the filter?

I don't understand the second question, but "no filter" means a default filter of ClassFilterUtils.EVERYTHING

i.e. loading any class from that deployment will trigger a start.

https://svn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/src/main/java/org/jboss/classloading/spi/dependency/LifeCycle.java

[alesj]

Or, what happens if you try to load a class past the filter?

I don't understand the second question,

I mean what happens if you try to load org.acme.foo.Foo, but the filter is set to org.acme.bar.

Probably you would be able to load the class, but no change to REAL would happen?

btw: CL snapshot looks outdated wrt Deployers -- e.g. no "mvn deploy"?

[adrian.brock]

alesj wrote:

Or, what happens if you try to load a class past the filter?

I don't understand the second question,

I mean what happens if you try to load org.acme.foo.Foo, but the filter is set to org.acme.bar.

Probably you would be able to load the class, but no change to REAL would happen?

Correct.

[alesj]

I mean what happens if you try to load org.acme.foo.Foo, but the filter is set to org.acme.bar.

Probably you would be able to load the class, but no change to REAL would happen?

      public void classFound(ClassFoundEvent event)
      {
         if (getLazyStartFilter().matchesClassName(event.getClassName()) == false)
            return;
         
         removeLazyStart();
         if (isStarted() == false)
         {
            try
            {
               start();

:-)

[adrian.brock]

btw: CL snapshot looks outdated wrt Deployers -- e.g. no "mvn deploy"?

Yep, my "mvn deploy" failed because of some transient problem, but I didn't spot it.

Uploading now....

[alesj]

Yep, my "mvn deploy" failed because of some transient problem, but I didn't spot it.

Perhaps a bit unrelated, unless you saw the same thing. :-)

I see this failure here and there -- quite randomly -- mostly always works on the 2nd pass.

Failed tests:
  testAbstractFactoryConcurrent(org.jboss.test.classloader.delegate.test.DelegateUnitTestCase)

[alesj]

I propose we add a new META-INF/jboss-deployment.xml which would be some generic

metadata for this kind of processing and other possible deployment control parameters.

Yeah, this would definitely be needed / useful -- for MC/AS boot time.

    <!-- Deploy this deployment in the described stage initially - i.e. no classloader -->

    <required-stage>DESCRIBE</required-stage>

    <!-- Only create the classloader when somebody wants to import our package or module -->

    <lazy-resolve/>

I guess the usage of the 2nd <lazy-resolve> would mean required-stage beyond DESCRIBE doesn't make sense.

Same for <lazy-start> if the required stage is set to REAL or past.

[alesj]

I've hacked this here -- https://jira.jboss.org/jira/browse/JBDEPLOY-248:

[1] metadata - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-impl/src/main/java/org/jboss/deployers/plugins/classloading/DeploymentMetaData.java

[2] validation deployer -http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-impl/src/main/java/org/jboss/deployers/plugins/classloading/DeploymentValidationDeployer.java

So, the xml looks now like this

<deployment xmlns="urn:jboss:deployment:1.0" required-stage="POST_PARSE" lazy-resolve=true>
 
    <lazy-start-filter>com.acme.somepackage</lazy-start-filter>
 
</deployment>