You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by James Carman <ja...@carmanconsulting.com> on 2009/03/23 15:06:48 UTC
[ANNOUNCE] Syringe: A New IoC Framework for Wicket...
All,
I've added a new wicketstuff project to the "Wicket Stuff Core"
project called wicket-syringe. Syringe lets you do dependency
injection using any container you want using the same @Inject
annotation. Right now, it has built-in support for Spring, Guice, and
the new Web Beans API (JSR-299). Some other technologies I've got on
the todo list are EJB3, Picocontainer, and HiveMind (I couldn't
resist). If anyone has suggestions on others, please let me know or
feel free to add them. Here's an example:
public class MyPage extends WebPage
{
@Inject
private MyService myService;
public MyPage()
{
...
myService.doSomething();
...
}
}
In your application class (which must extend the
WicketPluginApplication class), you do:
public void init()
{
getPluginRegistry().registerPlugin(new SyringePlugin(this, new
SpringDependencyProvider(WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext()))));
}
So, basically all you have to do is pass in an implementation of the
DependencyProvider interface and Syringe takes care of the rest.
Syringe uses Commons Proxy to create the proxied dependency
references. So, if you require more robust proxying (like being able
to proxy classes as well as interfaces), you'll have to give your
SyringePlugin either a JavassistProxyFactory or CglibProxyFactory.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by James Carman <jc...@carmanconsulting.com>.
I'm getting ready to upgrade the version of Commons Proxy to
1.1-SNAPSHOT, though. The 1.1 version ensures that the proxies are
serializable. I'll get a release of 1.1 out soon (sending email to
commons group now to start up a discussion).
On Mon, Mar 23, 2009 at 2:23 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> Sweet! I'm going to take a look. Sounds very promising.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Mon, Mar 23, 2009 at 1:13 PM, James Carman
> <jc...@carmanconsulting.com>wrote:
>
>> On Mon, Mar 23, 2009 at 11:26 AM, Jeremy Thomerson
>> <je...@wickettraining.com> wrote:
>> > Great news James! For those who are looking to decide between the two,
>> how
>> > does this differ from / improve on the existing wicket-ioc project?
>>
>> 1. Much easier to extend. All you need to do is implement the
>> DependencyProvider interface.
>>
>> 2. You *always* use the @Inject annotation. The annotation types
>> don't change between different dependency provider implementations.
>>
>> 3. The proxying is done using Commons Proxy, so the code is much more
>> lightweight.
>>
>> 4. It uses the new wicket-plugin architecture (another
>> wicketstuff-core project), so the only restriction it places on your
>> application class is that it extends WicketPluginApplication. Other
>> "plugins" (like security, etc.) should be written this way, too.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Sweet! I'm going to take a look. Sounds very promising.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Mar 23, 2009 at 1:13 PM, James Carman
<jc...@carmanconsulting.com>wrote:
> On Mon, Mar 23, 2009 at 11:26 AM, Jeremy Thomerson
> <je...@wickettraining.com> wrote:
> > Great news James! For those who are looking to decide between the two,
> how
> > does this differ from / improve on the existing wicket-ioc project?
>
> 1. Much easier to extend. All you need to do is implement the
> DependencyProvider interface.
>
> 2. You *always* use the @Inject annotation. The annotation types
> don't change between different dependency provider implementations.
>
> 3. The proxying is done using Commons Proxy, so the code is much more
> lightweight.
>
> 4. It uses the new wicket-plugin architecture (another
> wicketstuff-core project), so the only restriction it places on your
> application class is that it extends WicketPluginApplication. Other
> "plugins" (like security, etc.) should be written this way, too.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by James Carman <jc...@carmanconsulting.com>.
On Mon, Mar 23, 2009 at 4:40 PM, Matej Knopp <ma...@gmail.com> wrote:
> Hi,
>
>> The wicket-plugin architecture doesn't define any callbacks. You can
>> register any object you want as a plugin. That's why I pass in the
>> application instance. I tinkered with the idea of having a
>> WicketPlugin interface with an initialize(Application) method, but
>> decided to keep it simple.
> what I don't understand is how is this different than just an object
> registry? You register object in there by it's class name and query it
> (by the class or interfaces). This doesn't really provide you much
> additional functionality to application metadata.
>
It's not different than an object registry. It *is* an object
registry. I don't register by the class name. I register it by the
class type. It does understand class hierarchies, though.
> Even worse, you can't have two "plugins" implementing same interface.
You don't need two plugins implementing the same interface typically.
However, it could be augmented to allow you to lookup multiple plugins
by type. Right now, it just allows you to lookup one (and if there
are multiple it throws an exception).
>
> You can take look at brix registry
> http://code.google.com/p/brix-cms/source/browse/trunk/brix-core/src/main/java/brix/registry/ExtensionPoint.java
> http://code.google.com/p/brix-cms/source/browse/trunk/brix-core/src/main/java/brix/registry/ExtensionPointRegistry.java
>
> this actually is suitable for plugins because extensionpoint enforces
> certain kind of objects (plugins) so the part of application that
> needs to have it's functionality extended by plugins will know that
> all objects registered with it's extensionpoint will provide it.
I like that idea and I've implemented similar functionality before on
other projects. I suppose you could just register an ExtensionPoint
with the metadata and add extensions to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by Matej Knopp <ma...@gmail.com>.
Hi,
> The wicket-plugin architecture doesn't define any callbacks. You can
> register any object you want as a plugin. That's why I pass in the
> application instance. I tinkered with the idea of having a
> WicketPlugin interface with an initialize(Application) method, but
> decided to keep it simple.
what I don't understand is how is this different than just an object
registry? You register object in there by it's class name and query it
(by the class or interfaces). This doesn't really provide you much
additional functionality to application metadata.
Even worse, you can't have two "plugins" implementing same interface.
You can take look at brix registry
http://code.google.com/p/brix-cms/source/browse/trunk/brix-core/src/main/java/brix/registry/ExtensionPoint.java
http://code.google.com/p/brix-cms/source/browse/trunk/brix-core/src/main/java/brix/registry/ExtensionPointRegistry.java
this actually is suitable for plugins because extensionpoint enforces
certain kind of objects (plugins) so the part of application that
needs to have it's functionality extended by plugins will know that
all objects registered with it's extensionpoint will provide it.
-Matej
>
>>
>> right now its just a registry - we already have such a registry, its
>> called metadata. in fact the architecture does not even have to have a
>> base class for the application - if it stores the registry in metadata
>> it can simply be:
>>
>> PluginRegistry.get(application).foo(); or even shorter
>> PluginRegistry.get().foo();
>>
>
> I will look into that. The metadata functionality isn't something I'm
> completely familiar with and I didn't realize that it was to be used
> in this fashion. Thank you for your suggestions.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by James Carman <jc...@carmanconsulting.com>.
On Mon, Mar 23, 2009 at 3:22 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> if i want to use guice i should use guice...that toally makes sense :)
I mean that if you want to use all of the features that Guice offers
in your wicket components, then Syringe is not for you. Syringe is
perfectly capable of binding in your Guice-configured objects. What I
would recommend is that you push your logic into your classes that
you're going to be configuring via Guice. That's what folks will be
doing with WebBeans (if they use it), so that all of the
annotation-based goodies may be used (like scoping, interceptors,
etc.)
> my point was that the architecture is not there
>
> getPluginRegistry().registerPlugin(new SyringePlugin(this, new
> SpringDependencyProvider(WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext()))));
>
> should really be
>
> getPluginRegistry().register(new SpringSyringePlugin());
>
> everything else should be provided by the plugin framework's callback
> on your plugin. you should not have to pass in the application
> instance, and you should not have to pass in the servlet context.
The wicket-plugin architecture doesn't define any callbacks. You can
register any object you want as a plugin. That's why I pass in the
application instance. I tinkered with the idea of having a
WicketPlugin interface with an initialize(Application) method, but
decided to keep it simple.
>
> right now its just a registry - we already have such a registry, its
> called metadata. in fact the architecture does not even have to have a
> base class for the application - if it stores the registry in metadata
> it can simply be:
>
> PluginRegistry.get(application).foo(); or even shorter
> PluginRegistry.get().foo();
>
I will look into that. The metadata functionality isn't something I'm
completely familiar with and I didn't realize that it was to be used
in this fashion. Thank you for your suggestions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by Igor Vaynberg <ig...@gmail.com>.
On Mon, Mar 23, 2009 at 11:57 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> On Mon, Mar 23, 2009 at 2:51 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> what happens when features of differnet containers need to bleed
>> through? for example Guice's @Inject has an optional() attribute.
>> Since users of wicket-guice use guice's own @Inject it is all
>> transparently supported.
>
> Syringe doesn't support that. If you want to use Guice, you should use Guice.
if i want to use guice i should use guice...that toally makes sense :)
>> this pattern has proved quiet problematic in the past, and will keep
>> doing so until everybody uses the wicketpluginapplication base class
>> for the plugins they write for wicket. you should support a way of
>> working with syringe without the base class present.
>
> That doesn't mean it's not a good idea. If the architecture is there,
> then folks can start migrating to it. The beauty of the plugin
> architecture is that the injector logic can lookup the
> DependencyProvider at runtime (even after serialization). I suppose I
> could come up with a way to do that without the plugin architecture,
> but then nobody will use wicket-plugin! :)
my point was that the architecture is not there
getPluginRegistry().registerPlugin(new SyringePlugin(this, new
SpringDependencyProvider(WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext()))));
should really be
getPluginRegistry().register(new SpringSyringePlugin());
everything else should be provided by the plugin framework's callback
on your plugin. you should not have to pass in the application
instance, and you should not have to pass in the servlet context.
right now its just a registry - we already have such a registry, its
called metadata. in fact the architecture does not even have to have a
base class for the application - if it stores the registry in metadata
it can simply be:
PluginRegistry.get(application).foo(); or even shorter
PluginRegistry.get().foo();
anyways, this is a whole other topic.
-igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by James Carman <jc...@carmanconsulting.com>.
On Mon, Mar 23, 2009 at 2:51 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> what happens when features of differnet containers need to bleed
> through? for example Guice's @Inject has an optional() attribute.
> Since users of wicket-guice use guice's own @Inject it is all
> transparently supported.
Syringe doesn't support that. If you want to use Guice, you should use Guice.
> Reversely, syringe.Inject offers a name attribute, which afaik, guice
> does not support...
Guice supports the @Named attribute. Syringe supports that (it's in
the test case).
> you mean syringe does not have the portion of code that deals with
> cglib? that has been farmed out to commons-proxy? i dont see how this
> is a differentiating feature though unless you expect your users to
> work with syringe code that creates proxies?
It's different in that the code doesn't need to deal with it. If you
want to use a different proxying technology, you plug it in (the
SyringePlugin constructor can take a ProxyFactory).
> this pattern has proved quiet problematic in the past, and will keep
> doing so until everybody uses the wicketpluginapplication base class
> for the plugins they write for wicket. you should support a way of
> working with syringe without the base class present.
That doesn't mean it's not a good idea. If the architecture is there,
then folks can start migrating to it. The beauty of the plugin
architecture is that the injector logic can lookup the
DependencyProvider at runtime (even after serialization). I suppose I
could come up with a way to do that without the plugin architecture,
but then nobody will use wicket-plugin! :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by Igor Vaynberg <ig...@gmail.com>.
On Mon, Mar 23, 2009 at 11:13 AM, James Carman
<jc...@carmanconsulting.com> wrote:
> On Mon, Mar 23, 2009 at 11:26 AM, Jeremy Thomerson
> <je...@wickettraining.com> wrote:
>> Great news James! For those who are looking to decide between the two, how
>> does this differ from / improve on the existing wicket-ioc project?
>
> 1. Much easier to extend. All you need to do is implement the
> DependencyProvider interface.
>
> 2. You *always* use the @Inject annotation. The annotation types
> don't change between different dependency provider implementations.
what happens when features of differnet containers need to bleed
through? for example Guice's @Inject has an optional() attribute.
Since users of wicket-guice use guice's own @Inject it is all
transparently supported.
if i want to use that feature with syringe will i have to do
@syringe.Inject
@syringe.guice.Guice(optional=true)
Reversely, syringe.Inject offers a name attribute, which afaik, guice
does not support...
Just trying to figure out how a unified annotation will work with
containers that are so different.
> 3. The proxying is done using Commons Proxy, so the code is much more
> lightweight.
you mean syringe does not have the portion of code that deals with
cglib? that has been farmed out to commons-proxy? i dont see how this
is a differentiating feature though unless you expect your users to
work with syringe code that creates proxies?
> 4. It uses the new wicket-plugin architecture (another
> wicketstuff-core project), so the only restriction it places on your
> application class is that it extends WicketPluginApplication. Other
> "plugins" (like security, etc.) should be written this way, too.
this pattern has proved quiet problematic in the past, and will keep
doing so until everybody uses the wicketpluginapplication base class
for the plugins they write for wicket. you should support a way of
working with syringe without the base class present.
-igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by James Carman <jc...@carmanconsulting.com>.
On Mon, Mar 23, 2009 at 11:26 AM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> Great news James! For those who are looking to decide between the two, how
> does this differ from / improve on the existing wicket-ioc project?
1. Much easier to extend. All you need to do is implement the
DependencyProvider interface.
2. You *always* use the @Inject annotation. The annotation types
don't change between different dependency provider implementations.
3. The proxying is done using Commons Proxy, so the code is much more
lightweight.
4. It uses the new wicket-plugin architecture (another
wicketstuff-core project), so the only restriction it places on your
application class is that it extends WicketPluginApplication. Other
"plugins" (like security, etc.) should be written this way, too.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: [ANNOUNCE] Syringe: A New IoC Framework for Wicket...
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Great news James! For those who are looking to decide between the two, how
does this differ from / improve on the existing wicket-ioc project?
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Mar 23, 2009 at 9:06 AM, James Carman <ja...@carmanconsulting.com>wrote:
> All,
>
> I've added a new wicketstuff project to the "Wicket Stuff Core"
> project called wicket-syringe. Syringe lets you do dependency
> injection using any container you want using the same @Inject
> annotation. Right now, it has built-in support for Spring, Guice, and
> the new Web Beans API (JSR-299). Some other technologies I've got on
> the todo list are EJB3, Picocontainer, and HiveMind (I couldn't
> resist). If anyone has suggestions on others, please let me know or
> feel free to add them. Here's an example:
>
> public class MyPage extends WebPage
> {
> @Inject
> private MyService myService;
>
> public MyPage()
> {
> ...
> myService.doSomething();
> ...
> }
> }
>
> In your application class (which must extend the
> WicketPluginApplication class), you do:
>
> public void init()
> {
> getPluginRegistry().registerPlugin(new SyringePlugin(this, new
>
> SpringDependencyProvider(WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext()))));
> }
>
> So, basically all you have to do is pass in an implementation of the
> DependencyProvider interface and Syringe takes care of the rest.
> Syringe uses Commons Proxy to create the proxied dependency
> references. So, if you require more robust proxying (like being able
> to proxy classes as well as interfaces), you'll have to give your
> SyringePlugin either a JavassistProxyFactory or CglibProxyFactory.
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>