You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/10/22 20:33:00 UTC

Mass update to components for Cocoon 2.2

I am almost ready to get rid of the CocoonComponentManager, and the associated
ServiceSelectors.  This process will require me to make some massive changes
to the tree builder and language integration components.  I have some
rudimentary beginnings, but it is far from functional.  I am going to restart
those changes.

In the mean time, there are a lot of components that need meta information added
to them.  I would appreciate any help in this regard because it is fairly busy
work.

Do recognize that while Fortress will fall back on using the old Poolable,
ThreadSafe, and SingleThreaded lifestyle marker interfaces, all of these should
be avoided.  For Recyclable components, we should change them to
Resettable.reset().  I believe I have already done this much.

The set of meta info for the implementation classes is as follows:

@avalon.component
@avalon.service type="ServiceName"
@avalon.dependency type="ServiceName"
@x-avalon.lifestyle type="pooled"
@fortress.handler 
type="org.apache.cocoon.components.RequestLifestyleComponentHandler"
@x-avalon.info name="foo"

To better demonstrate how things would work:

/**
  *
  * The <code>FileGenerator</code> is a class that reads XML from a source
  * and generates SAX Events.
  * The FileGenerator implements the <code>CacheableProcessingComponent</code> 
interface.
  *
  * @author <a href="mailto:pier@apache.org">Pierpaolo Fumagalli</a>
  *         (Apache Software Foundation)
  * @author <a href="mailto:cziegeler@apache.org">Carsten Ziegeler</a>
  * @version CVS $Id: FileGenerator.java,v 1.5 2003/09/18 14:43:48 vgritsenko Exp $
  *
  * @avalon.component
  * @avalon.service type="Generator"
  * @x-avalon.lifestyle type="pooled"
  * @x-avalon.info name="file-generator"
  */
public class FileGenerator extends ServiceableGenerator
implements CacheableProcessingComponent {
     // ....
}


Let me provide some clarifications.

@x-avalon.lifestyle type="typename"

only works with the following values: "singleton, "thread", "pooled",
and "transient".  That's all.  If we have RequestLifecycle components,
then the info to add for that is:

@fortress.handler 
type="org.apache.cocoon.components.RequestLifestyleComponentHandler"

Unfortunately, there is no easy way around this for the time being.

The name in the @x-avalon.info name="component-name" is the same thing
as what you would find in the shorthand declaration in your roles file.

@avalon.service type="Generator"

The service declaration will resolve against any imported class you have
in your header.  If the import does not exist, then you need to specify
the full interface name.  One entry per service supported.  Usually this
means only one entry.  It corresponds to the lookup role for the component.
Having more than one @avalon.service entry will provide more than one
lookup role being available to find this component.

The @avalon.component entry must exist for all full fledged components.

For components that depend on other components to do their job, please
add the following to the Serviceable.service() implementation:

/**
  * This component depends on the following:
  *
  * @avalon.dependency type="Generator"
  * @avalon.dependency type="Transformer"
  * @avalon.dependency type="Serializer"
  */
public void service(ServiceManager manager) throws ServiceException
{
     manager.lookup(Generator.ROLE);
     manager.lookup(Transformer.ROLE);
     manager.lookup(Serializer.ROLE);
}

This allows Fortress to guarantee a proper shutdown order for the components,
and to guarantee that there are no circular dependencies.  The type parameter
is a class name (interface in this case) that can be resolved against your
import statements.  The services your component uses should be declared in the
imports by default anyway.  If not, and you are proxying for another component
that does the actual lookup, then you will have to add the fully qualified
class name.

Any help along these lines would be very much apreciated.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin



Re: Mass update to components for Cocoon 2.2

Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:

> Berin Loritsch wrote:
> 
>>Carsten Ziegeler wrote:
>>
>>
>>>I saw the changes from Recyclable to Resettable in 2.2.
>>>
>>>What does this mean for existing components? Is Recyclable
>>>still supported?
>>
>>If that class is loaded, yes.  If the Recyclable class is not
>>available, then the Classloader will not allow the existing
>>component to load.
>>
>>IOW, as long as the org.apache.avalon.excalibur.pool.Recyclable
>>interface exists somewhere in the classpath, all is well.  It
>>is still supported.
>>
> 
> So, if we ship 2.2 with that class, "old" components still work
> as expected.

Yep.  THe MPool system uses reflection to check for that old contract.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


RE: Mass update to components for Cocoon 2.2

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
> 
> Carsten Ziegeler wrote:
> 
> > I saw the changes from Recyclable to Resettable in 2.2.
> > 
> > What does this mean for existing components? Is Recyclable
> > still supported?
> 
> If that class is loaded, yes.  If the Recyclable class is not
> available, then the Classloader will not allow the existing
> component to load.
> 
> IOW, as long as the org.apache.avalon.excalibur.pool.Recyclable
> interface exists somewhere in the classpath, all is well.  It
> is still supported.
> 
So, if we ship 2.2 with that class, "old" components still work
as expected.

Thanks
Carsten

Re: Mass update to components for Cocoon 2.2

Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:

> I saw the changes from Recyclable to Resettable in 2.2.
> 
> What does this mean for existing components? Is Recyclable
> still supported?

If that class is loaded, yes.  If the Recyclable class is not
available, then the Classloader will not allow the existing
component to load.

IOW, as long as the org.apache.avalon.excalibur.pool.Recyclable
interface exists somewhere in the classpath, all is well.  It
is still supported.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


RE: Mass update to components for Cocoon 2.2

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
>
> >
> > So, we can remove it from everywhere (in 2.2). Should we do it?
>
> There is no reason I can think of that would require it...
>
Sometime in the future, Component will be really deprecated and then we have
to remove it in order to get rid off the nice warnings. Perhaps, we
could simply do it now and relax when this happens ;)

Carsten


Re: Mass update to components for Cocoon 2.2

Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:

> Berin Loritsch wrote:
> 
>>Carsten Ziegeler wrote:
>>
>>
>>>Another question :)
>>>
>>>Currently with ECM we have to implement the Component interface
>>>even if we only use Serviceable (because of the internal
>>>handling with the proxies etc.)
>>>
>>>Do we still need this with Fortress? I guess: no.
>>
>>No, this is not needed at all.
>>
> 
> So, we can remove it from everywhere (in 2.2). Should we do it?

There is no reason I can think of that would require it...



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


RE: Mass update to components for Cocoon 2.2

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
> 
> Carsten Ziegeler wrote:
> 
> > Another question :)
> > 
> > Currently with ECM we have to implement the Component interface
> > even if we only use Serviceable (because of the internal
> > handling with the proxies etc.)
> > 
> > Do we still need this with Fortress? I guess: no.
> 
> No, this is not needed at all.
> 
So, we can remove it from everywhere (in 2.2). Should we do it?

Carsten

Re: Mass update to components for Cocoon 2.2

Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:

> Another question :)
> 
> Currently with ECM we have to implement the Component interface
> even if we only use Serviceable (because of the internal
> handling with the proxies etc.)
> 
> Do we still need this with Fortress? I guess: no.

No, this is not needed at all.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


RE: Mass update to components for Cocoon 2.2

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Another question :)

Currently with ECM we have to implement the Component interface
even if we only use Serviceable (because of the internal
handling with the proxies etc.)

Do we still need this with Fortress? I guess: no.

Carsten

RE: Mass update to components for Cocoon 2.2

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I saw the changes from Recyclable to Resettable in 2.2.

What does this mean for existing components? Is Recyclable
still supported?

Carsten