You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Glenn Sudduth <gs...@gmail.com> on 2008/03/22 00:02:11 UTC
T5 IoC question ...
(This seems like a pretty basic question, but I haven't been able to
ferret out the answer so here goes ...)
What is a good way to have Tapestry 5 IoC determine which implementation
of a particular service to load at runtime? With Spring I accomplish
this by creating multiple versions of the bean definition/config file.
Then have the (Maven) build process select the appropriate config based
on the build profile I specify (dev, test, prod) and copy it in place so
that Spring reads it when it starts up.
Thanks,
--
Glenn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 IoC question ...
Posted by Robert Zeigler <ro...@scazdl.org>.
Plenty of reasons to have different service implementations per
environment.
A big one for me is authentication. Same app may have different
authentication strategies depending on environment. LDAP here, db-
backed there, simple (or none) for development, etc.
There are a number of ways that I could see approaching this.
One way would be to contribute your own ObjectProvider, which then
resolves the services according to whatever configuration you want.
Another way would utilize the AliasOverrides service.
The easiest way to explain this is probably to step through an
example, so, for the authentication example:
Note that although all of the following examples will use service ids,
you could easily create your own service markers (@Default, @LDAP,
etc.) if you wanted to do this in a "refactor-safe" manner.
Authenticator will refer to the name of an interface defining
appropriate methods for authentication.
AppModule.java:
public static void bind(ServiceBinder binder) {
binder
.bind(Authenticator.class,DefaultAuthenticator.class).withId("default");
}
public static void
contributeAlias(Configuration<AliasContribution> conf,
@InjectService("default") Authenticator auth) {
conf.add(Authenticator.class,auth);
}
Now suppose you have a client that uses ldap authentication. You
create a new library. It can be very small, with two classes: your
ldap authentication implementation, and your ldap module.
LDAPModule.java:
public static void bind(ServiceBinder binder) {
binder.bind(Authenticator.class,LDAPAuthenticator.class).withId("ldap");
}
public static void
contributeAliasOverrides(Configuration<AliasContribution> conf,
@InjectService("ldap") Authenticator auth) {
conf.add(Authentication.class,auth);
}
Now you've got that setup to be packaged into a jar, you put the
tapestry-module line into your manifest (running out of time here or
I'd post a link), so the ioc can auto-load your module.
Finally, you setup your maven profile so that your development build
doesn't depend on the LDAP module, but your build for the client that
uses LDAPAuthentication /does/ depend on the LDAP module.
Now the correct service will be selected based on the presence or
absence of the appropriate modules.
Robert
On Mar 21, 2008, at 3/216:29 PM , Ben Tomasini wrote:
> Glenn,
>
> What requires you to have separate implementations for each
> environment? Is it configuration data that you could move into a
> properties file that lives the in the classpath of your container?
>
> Ben
>
> On Fri, Mar 21, 2008 at 4:02 PM, Glenn Sudduth <gs...@gmail.com>
> wrote:
>> (This seems like a pretty basic question, but I haven't been able to
>> ferret out the answer so here goes ...)
>>
>> What is a good way to have Tapestry 5 IoC determine which
>> implementation
>> of a particular service to load at runtime? With Spring I accomplish
>> this by creating multiple versions of the bean definition/config
>> file.
>> Then have the (Maven) build process select the appropriate config
>> based
>> on the build profile I specify (dev, test, prod) and copy it in
>> place so
>> that Spring reads it when it starts up.
>> Thanks,
>> --
>> Glenn
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 IoC question ...
Posted by Howard Lewis Ship <hl...@gmail.com>.
On option is inside your contributeMasterDispatcher() contribution
method, you decide then and there which of two versions to contribute:
a development mode version or a production mode version. You can
inject
@Symbol(TapestryConstants.PRODUCTION_MODE_SYMBOL) boolean productionMode
into the method to help you decide.
On Fri, Mar 21, 2008 at 4:50 PM, Glenn Sudduth <gs...@gmail.com> wrote:
> I don't think so. The problem I am trying to solve in this case is that
> I have a Dispatcher that performs authentication and authorization in
> the Tapestry request pipeline (I'm very new to T5 so I hope I'm using
> sane terms there). In the dev environment I need the implementation to
> not have external dependencies.
>
> Thanks,
> --
> Glenn
>
>
>
> On Fri, 2008-03-21 at 16:29 -0700, Ben Tomasini wrote:
> > Glenn,
> >
> > What requires you to have separate implementations for each
> > environment? Is it configuration data that you could move into a
> > properties file that lives the in the classpath of your container?
> >
> > Ben
> >
> > On Fri, Mar 21, 2008 at 4:02 PM, Glenn Sudduth <gs...@gmail.com> wrote:
> > > (This seems like a pretty basic question, but I haven't been able to
> > > ferret out the answer so here goes ...)
> > >
> > > What is a good way to have Tapestry 5 IoC determine which implementation
> > > of a particular service to load at runtime? With Spring I accomplish
> > > this by creating multiple versions of the bean definition/config file.
> > > Then have the (Maven) build process select the appropriate config based
> > > on the build profile I specify (dev, test, prod) and copy it in place so
> > > that Spring reads it when it starts up.
> > > Thanks,
> > > --
> > > Glenn
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 IoC question ...
Posted by Glenn Sudduth <gs...@gmail.com>.
I don't think so. The problem I am trying to solve in this case is that
I have a Dispatcher that performs authentication and authorization in
the Tapestry request pipeline (I'm very new to T5 so I hope I'm using
sane terms there). In the dev environment I need the implementation to
not have external dependencies.
Thanks,
--
Glenn
On Fri, 2008-03-21 at 16:29 -0700, Ben Tomasini wrote:
> Glenn,
>
> What requires you to have separate implementations for each
> environment? Is it configuration data that you could move into a
> properties file that lives the in the classpath of your container?
>
> Ben
>
> On Fri, Mar 21, 2008 at 4:02 PM, Glenn Sudduth <gs...@gmail.com> wrote:
> > (This seems like a pretty basic question, but I haven't been able to
> > ferret out the answer so here goes ...)
> >
> > What is a good way to have Tapestry 5 IoC determine which implementation
> > of a particular service to load at runtime? With Spring I accomplish
> > this by creating multiple versions of the bean definition/config file.
> > Then have the (Maven) build process select the appropriate config based
> > on the build profile I specify (dev, test, prod) and copy it in place so
> > that Spring reads it when it starts up.
> > Thanks,
> > --
> > Glenn
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 IoC question ...
Posted by Ben Tomasini <be...@gmail.com>.
Glenn,
What requires you to have separate implementations for each
environment? Is it configuration data that you could move into a
properties file that lives the in the classpath of your container?
Ben
On Fri, Mar 21, 2008 at 4:02 PM, Glenn Sudduth <gs...@gmail.com> wrote:
> (This seems like a pretty basic question, but I haven't been able to
> ferret out the answer so here goes ...)
>
> What is a good way to have Tapestry 5 IoC determine which implementation
> of a particular service to load at runtime? With Spring I accomplish
> this by creating multiple versions of the bean definition/config file.
> Then have the (Maven) build process select the appropriate config based
> on the build profile I specify (dev, test, prod) and copy it in place so
> that Spring reads it when it starts up.
> Thanks,
> --
> Glenn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org