2013/9/19 Lukasz Lenart [lukaszlen...@apache.org]:
2013/9/18 Patrick Savage patrick.sav...@3pillarglobal.com:
We are using XWork's @Inject in Struts 2.3.1.2 to inject a
DefaultObjectTypeDeterminer into a custom type converter. Since upgrading
from Java 1.6.0_33 to 1.7.0_25, this injection does not occur about half the
time. The other @Inject we use (injecting a ValidatorFactory into a custom
ActionValidatorManager configured by struts.actionValidatorManager in
struts.xml) is still always working. There are no log messages at any log
level that indicate a problem. The container successfully creates the custom
type converter bean as evidenced by the log message
java.util.List:com.candyland.web.converters.CandylandCollectionConverter
[treated as TypeConverter
com.candyland.web.converters.CandylandCollectionConverter@245f96b0].
Is it possible that this problem occurs because the getDeclaredMethods
method in Java 7 no longer returns methods in a consistent order
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7023180)?. Per
https://groups.google.com/forum/#!topic/google-guice/rQD5L2O-Po8, this
causes Guice to inject objects in an inconsistent order so presumably the
Struts container would do the same, but I don't know if that would have any
negative effects.
This is strange ... as @Inject is used all over the framework and works fine.
This is the relevant code:
xwork-conversion.properties:
java.util.List=com.candyland.web.converters.CandylandCollectionConverter
...
CandylandCollectionConverter.java:
public class CandylandCollectionConverter extends
XWorkBasicConverter {
private ObjectTypeDeterminer objectTypeDeterminer;
@Inject
public void setObjectTypeDeterminer(ObjectTypeDeterminer
det) {
this.objectTypeDeterminer = det;
super.setObjectTypeDeterminer(det);
}
...
}
As a workaround, we lazily get the DefaultObjectTypeDeterminer by calling
Dispatcher.getInstance().getContainer().getInstance(ObjectTypeDeterminer.cla
ss). This seems to be a reasonable workaround, but is there a way to fix the
injection?
Maybe direct reference to Container would be better solution? And then
lazy obtain reference to ObjectTypeDeterminer?
@Inject
public void setContainer(Container container) {
objectTypeDeterminer = container.getInstance(ObjectTypeDeterminer.class);
}
I think the problem is in setter overriding.
What version of Struts do you use? Sometime ago I have split
XWorkBasicConverter into bunch of small converters which you can
re-implement and redeclare. Or maybe instead inheritance you can use
composition?
public class CandylandCollectionConverter implements TypeConverter {
@Inject
XWorkBasicConverter
@Inject
ObjectTypeDeterminer
}
I don't think the setter overridding is the problem because I have also tried
injecting into a different method (setObjectTypeDeterminerOverride) which
didn't work either. Injecting the container doesn't work either because all
injections into CandylandCollectionConverter are skipped (I have already tried
injecting an ObjectFactory, ReflectionProvider, and a XWorkConverter). I also
have already tried composition although the containing converter still
inherited from XWorkBasicConverter.
I'm using Struts 2.3.1.2 so I don't have your WW-3762 change in 2.3.3 that
split XWorkBasicConverter into smaller converters. But we are planning to
upgrade to the latest version soon so I will try that then.
Is our current workaround which lazily calls
Dispatcher.getInstance().getContainer().getInstance(ObjectTypeDeterminer.class)
a reasonable long-term solution?
Martin, I know the Struts DI container is not Guice, but it is based on an old
version of Guice which is why I suspected that Java 7 change could be related.
--
Patrick
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
