[RFC] refactoring of our plugin API

[Mark Struberg <st...@yahoo.de>]

Hi!

I grabed a lot of info this week and now like to hear what you think of the following approach.

Currently our plugin API (org.apache.webbeans.plugins.OpenWebBeansPlugin) has a lot functions which have simply been taken from our original internal implementation and changed to be iterable over all registered plugins.

Since about 2 month, the JSR-299 spec contains a lot of SPI interfaces itself, and while they most times don't force us to change our internal architecture, it sometimes would make more sense to strongly adopt it. 

So I e.g. ask myself if it would be a good idea to completely rewrite our plugin API and only check if the plugin provides functionality for a specific use case and return the proper spi interface if it likes to handle it.

e.g. instead of 
public void isManagedBean(Class<?> clazz) throws WebBeansConfigurationException;
public Object injectResource(Type type, Annotation[] annotations);

we may also define a 

Producer<T> handleProduction(Class<T> clazz); (maybe we need additional parameters)

If a certain plugin likes to handle the clazz, it returns the Producer for it. E.g. if the clazz is a @Stateful session bean, the EjbPlugin will return a EjbBeanProducerImpl or something.

I'm not sure if you can follow my thoughts, but I hope you get the direction.

It's basically about moving the plugin API to a higher abstraction level and not dealing with as much implementation details as we currently do.

wdyt?

LieGrue,
strub



      

Re: [RFC] refactoring of our plugin API

[Gurkan Erdogdu <gu...@yahoo.com>]

Hi Mark;

Could you look at the EJB plugin that I wrote ? . It is not generic and it handles all of the EJB use cases defined in the spec.(i.e, OpenWebBeansEJBPlugin defines SPI that provides necessary hooks for WebBeans container.)  I also thought about your concern that all of the plugin functionalities must be based on specific SPIs like I did for EJB.  For example, I will write OpenWebBeansResourcePlugin that will define resource injections SPI, like this

public class OpenWebBeansResourcePlugin extends OpenWebBeansPlugin
{
    public Object injectEjb(EjbDescriptor blabla);

    public Object injectWebService(WebServiceDesciriptor blabla);

    public Object injectEntityManager(EntityManager blabla)
}

Than, I will implement this for OpenEjb container.

Currently, we have other plugins that work more like a service

- OpenWebBeansJmsPlugin
- OpenWebBeansJpaPlugin
- OpenWebBeansJsfPlugin

As you said, definitely we have to convert those plugin codes into a specific plugin code like I did for ejbs.Also we can remove the JPA plugin because I will write generic resource plugin for container injections.

I think that there is no need to refactor now. Because those plugins do not hurt our implementation for the time being. But if we add another plugin, we definitely implement it for producing a special SPI methods like Ejb plugin does.

But, if you think that some re-factoring is good, then go ahead and do it :)

Thanks;

Gurkan




________________________________
From: Mark Struberg <st...@yahoo.de>
To: openwebbeans-dev@incubator.apache.org
Sent: Sunday, August 9, 2009 1:37:31 PM
Subject: [RFC] refactoring of our plugin API


Hi!

I grabed a lot of info this week and now like to hear what you think of the following approach.

Currently our plugin API (org.apache.webbeans.plugins.OpenWebBeansPlugin) has a lot functions which have simply been taken from our original internal implementation and changed to be iterable over all registered plugins.

Since about 2 month, the JSR-299 spec contains a lot of SPI interfaces itself, and while they most times don't force us to change our internal architecture, it sometimes would make more sense to strongly adopt it. 

So I e.g. ask myself if it would be a good idea to completely rewrite our plugin API and only check if the plugin provides functionality for a specific use case and return the proper spi interface if it likes to handle it.

e.g. instead of 
public void isManagedBean(Class<?> clazz) throws WebBeansConfigurationException;
public Object injectResource(Type type, Annotation[] annotations);

we may also define a 

Producer<T> handleProduction(Class<T> clazz); (maybe we need additional parameters)

If a certain plugin likes to handle the clazz, it returns the Producer for it. E.g. if the clazz is a @Stateful session bean, the EjbPlugin will return a EjbBeanProducerImpl or something.

I'm not sure if you can follow my thoughts, but I hope you get the direction.

It's basically about moving the plugin API to a higher abstraction level and not dealing with as much implementation details as we currently do.

wdyt?

LieGrue,
strub