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 <[email protected]>
To: [email protected]
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
