Hi Philippe,
Sorry for the delay.
On 02/04/2012, at 06:25, Philippe Rabier wrote:
> Hi Henrique,
>
> I prepare my brain to use WOInject. I have a specific case where I need your
> help.
>
> We have 2 frameworks:
> - web services
> - foundation
>
> which have no dependency with WO, EOF, … ("pure" java I could say).
> Foundation provides factories used by web services but they return objects
> implementing java interfaces. This factory have a static method to set the
> class to instantiate like this:
> NFNotificationFetcherFactory.setCreateNotificationFetcherClass2Instantiate(MyClass.class);
>
> We have also a Business framework which relies on EOF and the framework
> principal initializes the factories with the concrete classes. (so calling
> the method above).
>
> So as you may imagine, I thought at first replacing this mechanism with
> WOInject.
>
That is an appropriate problem to solve with WOInject/Guice.
> I like the fact that our business framework initializes the factories. We
> have now 5 different apps using our business framework but they don't care
> what class must be instantiated. Using WOInject/Guice, I have the impression
> that the modules must be declared at a higher level aka the application. In
> my example above, web services knows foundation and business knows foundation
> but there is no dependency between web services and foundation.
>
The current version of WOInject doesn't provide an integration with the
framework principal mechanism provided by Wonder. You have to declare which
modules you want to load in each application class. You can, however, define
the module in your framework and declare the bindings in one place.
In the Business framework:
class BusinessModule extends AbstractModule {
protected void configure() {
bind(NotificationFetcher.class).to(MyClass.class);
...
}
}
Then, in your applications:
class Application extends InjectableApplication {
protected Module[] modules() {
return new Module[] { new BusinessModule() };
}
}
I've created an issue [1] on GitHub to address this feature.
> So I have 2 questions:
> - can a module be loaded by a framework principal in the finishInitialization
> method?
In the current version no, but I'm willing to implement it for the next
version. It is a nice addition. :)
> - is the injection mechanism efficient (in our case, a new object is created
> each time there is an http request)?
I still don't have any benchmarks comparing an application running with
WOInject and without it. Our empirical analysis didn't capture any
discrepancies over the application performance after the addition of WOInject.
I'll try to produce meaningful numbers when I finish a refactoring in the
WOInject initialization code. I'll probably replace the Javassist library by
ASM, which can lead to smaller performance gains.
Anyway, if you want to check it out, you can configure one application to use
WOInject in a few minutes. Even if you don't configure any Guice module,
components, EOs, DirectActions and Sessions will be created by Guice. Other
internal WebObjects classes will be instantiated via reflection, and I'll be
injected after that. If you feel your application is slow after the change, let
me know.
[1]https://github.com/hprange/woinject/issues/1
Cheers,
Henrique
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
