Re: Salve and Guice
Hi Edgar, did you use either static weaving or the runtime agent as described at http://code.google.com/p/salve/wiki/ConfiguringInstrumentation ? Kristof On Tue, Oct 21, 2008 at 11:42 AM, Edgar Merino [EMAIL PROTECTED] wrote: I've been searching for information on how to use guice to lookup dependencies with salve, the wiki only mentions how to add the guice locator but I believe that is not working (at least not by it self). I've got a class in a wicket application that is not a component, but I need a service injected, so I'm using salve for this, instead of using @Inject to inject the service I use @Dependency, but I'm getting nullpointerexceptions, any hint? Thank you, Edgar Merino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Salve and Guice
I haven't used Salve with Wicket, but I've been using the wicket-guice integration quite extensively. The reason I'm answering this is that I feel that many of the use cases of Salve can be solved with pure vanilla Guice. In cases where you can't control the instantiation of objects, you can use static injection, which is a bit dirty, but IMO cleaner than instrumentation. :) So this post is maybe a tiny bit off topic. :) The way I've been doing it is by using the guice-servlet package which allows you to extend a GuiceServletContextListener to create a Injector. To tell your servlet container about this, put something similar into your web.xml: listener listener-classdk.dtu.kiosk.guice.MyGuiceServletContextListener/listener-class /listener Then I use the wicket-guice integration for hooking the two together. To bootstrap Wicket with Guice you simply use the following in your web.xml filter filter-namemyApplication/filter-name filter-class org.apache.wicket.protocol.http.WicketFilter /filter-class init-param param-nameapplicationFactoryClassName/param-name param-value org.apache.wicket.guice.GuiceWebApplicationFactory /param-value /init-param init-param param-nameinjectorContextAttribute/param-name param-valuecom.google.inject.Injector/param-value /init-param /filter Voila! Now you can use the @Inject annotation in any Wicket component. You also have the option of using Providers if you need something dep. injected or in the difficult cases static injection. regards, Guðmundur Bjarni -- View this message in context: http://www.nabble.com/Salve-and-Guice-tp20087649p20088079.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Salve and Guice
there are cases where this approach plain old sucks.
as you mentioned, if its not a component you have to use static injection
which is fugly
class mydataprovider implements idataprovider {
public mydataprovider() {
InjectorHolder.getInjector().inject(this);
}
}
another problem is that the injector creates a proxy which in certain
situations cant be done. eg your dependency is a class from a 3rd party
library that does not have a default constructor, thus cglib cannot create a
proxy.
another advantage of salve is that it _removes_ the field from the class. so
your classes are smaller and there are no serialization problems whatsoever
as far as dependencies go.
-igor
On Tue, Oct 21, 2008 at 4:15 AM, Guðmundur Bjarni
[EMAIL PROTECTED] wrote:
I haven't used Salve with Wicket, but I've been using the wicket-guice
integration quite extensively. The reason I'm answering this is that I feel
that many of the use cases of Salve can be solved with pure vanilla Guice.
In cases where you can't control the instantiation of objects, you can use
static injection, which is a bit dirty, but IMO cleaner than
instrumentation. :) So this post is maybe a tiny bit off topic. :)
The way I've been doing it is by using the guice-servlet package which
allows you to extend a GuiceServletContextListener to create a Injector. To
tell your servlet container about this, put something similar into your
web.xml:
listener
listener-classdk.dtu.kiosk.guice.MyGuiceServletContextListener/listener-class
/listener
Then I use the wicket-guice integration for hooking the two together. To
bootstrap Wicket with Guice you simply use the following in your web.xml
filter
filter-namemyApplication/filter-name
filter-class
org.apache.wicket.protocol.http.WicketFilter
/filter-class
init-param
param-nameapplicationFactoryClassName/param-name
param-value
org.apache.wicket.guice.GuiceWebApplicationFactory
/param-value
/init-param
init-param
param-nameinjectorContextAttribute/param-name
param-valuecom.google.inject.Injector/param-value
/init-param
/filter
Voila! Now you can use the @Inject annotation in any Wicket component. You
also have the option of using Providers if you need something dep. injected
or in the difficult cases static injection.
regards,
Guðmundur Bjarni
--
View this message in context:
http://www.nabble.com/Salve-and-Guice-tp20087649p20088079.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Salve and Guice
I agree that static injection is fugly, it makes unit tests very sad and
kills puppies, but in some cases its a necessary evil. Lets say for example
that it is only needed in a very few cases, then IMO pulling in Salve is a
bit of an overkill. I've tried out Salve, liked it but it's a bit of a
commitment to use compile time weaving/instrumentation.
Last I checked, the InjectorHolder only worked with Spring and not with
Guice. I looked into fixing that some time ago but didn't finish that work.
I've got more time now if someone is interested? :)
regards,
Guðmundur Bjarni
igor.vaynberg wrote:
there are cases where this approach plain old sucks.
as you mentioned, if its not a component you have to use static injection
which is fugly
class mydataprovider implements idataprovider {
public mydataprovider() {
InjectorHolder.getInjector().inject(this);
}
}
another problem is that the injector creates a proxy which in certain
situations cant be done. eg your dependency is a class from a 3rd party
library that does not have a default constructor, thus cglib cannot create
a
proxy.
another advantage of salve is that it _removes_ the field from the class.
so
your classes are smaller and there are no serialization problems
whatsoever
as far as dependencies go.
-igor
--
View this message in context:
http://www.nabble.com/Salve-and-Guice-tp20087649p20100143.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Salve and Guice
As far as I know, salve will only modify bytecode, it should do that
only once, after the JIT compiler comes in there should be no more
overhead. Correct me if I'm wrong, regards.
Edgar Merino
Guðmundur Bjarni escribió:
I agree that static injection is fugly, it makes unit tests very sad and
kills puppies, but in some cases its a necessary evil. Lets say for example
that it is only needed in a very few cases, then IMO pulling in Salve is a
bit of an overkill. I've tried out Salve, liked it but it's a bit of a
commitment to use compile time weaving/instrumentation.
Last I checked, the InjectorHolder only worked with Spring and not with
Guice. I looked into fixing that some time ago but didn't finish that work.
I've got more time now if someone is interested? :)
regards,
Guðmundur Bjarni
igor.vaynberg wrote:
there are cases where this approach plain old sucks.
as you mentioned, if its not a component you have to use static injection
which is fugly
class mydataprovider implements idataprovider {
public mydataprovider() {
InjectorHolder.getInjector().inject(this);
}
}
another problem is that the injector creates a proxy which in certain
situations cant be done. eg your dependency is a class from a 3rd party
library that does not have a default constructor, thus cglib cannot create
a
proxy.
another advantage of salve is that it _removes_ the field from the class.
so
your classes are smaller and there are no serialization problems
whatsoever
as far as dependencies go.
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Salve and Guice
Also, InjectorHolder.getInjector().inject(this) does not work with
guice, it returns an illegalstateexception saying there's no injector
assigned for the holder. It would be nice to have more documentation on
how to use salve, regards.
Edgar Merino
Guðmundur Bjarni escribió:
I agree that static injection is fugly, it makes unit tests very sad and
kills puppies, but in some cases its a necessary evil. Lets say for example
that it is only needed in a very few cases, then IMO pulling in Salve is a
bit of an overkill. I've tried out Salve, liked it but it's a bit of a
commitment to use compile time weaving/instrumentation.
Last I checked, the InjectorHolder only worked with Spring and not with
Guice. I looked into fixing that some time ago but didn't finish that work.
I've got more time now if someone is interested? :)
regards,
Guðmundur Bjarni
igor.vaynberg wrote:
there are cases where this approach plain old sucks.
as you mentioned, if its not a component you have to use static injection
which is fugly
class mydataprovider implements idataprovider {
public mydataprovider() {
InjectorHolder.getInjector().inject(this);
}
}
another problem is that the injector creates a proxy which in certain
situations cant be done. eg your dependency is a class from a 3rd party
library that does not have a default constructor, thus cglib cannot create
a
proxy.
another advantage of salve is that it _removes_ the field from the class.
so
your classes are smaller and there are no serialization problems
whatsoever
as far as dependencies go.
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Salve and Guice
i am not sure where exactly the documentation lacks...there is a wiki that
shows how to configure everything. anyways, salve stuff is better taken to
the salve discussion group so we dont pollute this list.
-igor
On Tue, Oct 21, 2008 at 4:02 PM, Edgar Merino [EMAIL PROTECTED] wrote:
Also, InjectorHolder.getInjector().inject(this) does not work with guice,
it returns an illegalstateexception saying there's no injector assigned for
the holder. It would be nice to have more documentation on how to use salve,
regards.
Edgar Merino
Guðmundur Bjarni escribió:
I agree that static injection is fugly, it makes unit tests very sad and
kills puppies, but in some cases its a necessary evil. Lets say for
example
that it is only needed in a very few cases, then IMO pulling in Salve is a
bit of an overkill. I've tried out Salve, liked it but it's a bit of a
commitment to use compile time weaving/instrumentation.
Last I checked, the InjectorHolder only worked with Spring and not with
Guice. I looked into fixing that some time ago but didn't finish that
work.
I've got more time now if someone is interested? :)
regards,
Guðmundur Bjarni
igor.vaynberg wrote:
there are cases where this approach plain old sucks.
as you mentioned, if its not a component you have to use static injection
which is fugly
class mydataprovider implements idataprovider {
public mydataprovider() {
InjectorHolder.getInjector().inject(this);
}
}
another problem is that the injector creates a proxy which in certain
situations cant be done. eg your dependency is a class from a 3rd party
library that does not have a default constructor, thus cglib cannot
create
a
proxy.
another advantage of salve is that it _removes_ the field from the class.
so
your classes are smaller and there are no serialization problems
whatsoever
as far as dependencies go.
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
