Tck: CdiOptionalInjectionTest - bean loadable from two places->CDI deployment error #145
Comments
|
Please test with this fix - txs! |
|
Not sure that will have any effect as the inner class will get added anyway (I had already played with that, so I know it will have no effect:-) ) See the addClasses javadoc in Shrinkwrap. /** |
|
I think it should. Inner classes get automatically added with the top level class. Thus we did have it twice after manually adding it again. Now you should only see it once. |
|
Apologies but I have just tried this now (again, I had done it before) and it does not change the war file so test still fails. |
|
Weird, just checked with the debugger That's the jar content: Here is the content of the war: As you can see, the OptionalValuesBean.class exists only once. |
|
There must be something in my environment that is causing Shrinkwrap to behave differently. My war looks like this: So you also have much |
|
I guess the arquillian-connector-weld adds those files. That are just arquillian jars. How does your cdiOptionalInjectionTest.jar file look like? |
|
The jar looks really plain (just like yours above). private List<Archive<?>> loadAuxiliaryArchives(DeploymentDescription deployment)
{
List<Archive<?>> archives = new ArrayList<Archive<?>>();
// load based on the Containers ClassLoader
Collection<AuxiliaryArchiveAppender> archiveAppenders = serviceLoader.get().all(AuxiliaryArchiveAppender.class);
for(AuxiliaryArchiveAppender archiveAppender : archiveAppenders)
{
Archive<?> auxiliaryArchive = archiveAppender.createAuxiliaryArchive();
if(auxiliaryArchive != null)
{
archives.add(auxiliaryArchive);
}
}
return archives;
...
from...
loadAuxiliaryArchives(DeploymentDescription deployment)
buildTestableDeployments(DeploymentScenario scenario, TestClass testCase, ProtocolRegistry protoReg)
createTestableDeployments(DeploymentScenario scenario, TestClass testCase)
generateDeployment(@Observes GenerateDeployment event)and the testcase is added to the war (as well as already being in the jar) by the try
{
// this should be made more reliable, does not work with e.g. a EnterpriseArchive
if(ClassContainer.class.isInstance(applicationArchive))
{
ClassContainer<?> classContainer = ClassContainer.class.cast(applicationArchive);
classContainer.addClass(testCase.getJavaClass()); //<<<<<<<<<<<<<<< hereI will have a bit more investigation on how to control this better... |
|
The Arquillian code seems (to me) to always add the test class (and any inner classes) to the war in |
|
Hi @hutchig! If you see the class twice, then that might be a bug in the Arquillian adaptor of Liberty. |
|
The Arquillian DeploymentGenerator is not container specific and the buildTestableDeployments:classContainer.addClass(testCase.getJavaClass())is not conditional (as far as I can tell) on any container attributes. If I run the built war in wildfly 10 I get exactly the same deployment problem: Does the way you run the tck leave wars in the filesystem (target dir) after you run the tests? It is possible the way you run might be taking the other branch of the conditional if(ClassContainer.class.isInstance(applicationArchive)) I will have a look if I can take the same branch. |
|
@hutchig please do the following in your debugger StringBuilder sb = new StringBuilder(); then check which resource paths you get for the class. My guess is that isolation of the @deployment from your whole test classpath is not provided by your arquillian provider. But just a blind guess of course... |
|
Forgive me a little for veering off slightly Mark @struberg as I know this is QQ (or QS!) and not QAQA... GIven the way the war as it is built on disk, I an sure it is correct that WELD throws a CDI error All the code the user requested to be in the archive is in the one jar and overall there is only one war - so WELD is correct to think app code could/should easily load from the two places the bean Certainly, the thread context classloader that is part of the mp config spec as seen by the test code will be able to load from the same jar and the WEB-INF/lib of the war the jar is in - so I am certain that there is no relevant classloader here in JEE that should not be able to see both .class resources. For classloading, this is no problem at all as the first linkable .class resource found (in class/parent/diskloader_delegation_chainclasspath) will be used. I think there are a few possibilities I can explore now that might resolve the issue given the current Arquillian core (i.e. not container specific connector) implementation:
|
|
Test runs fine if the injected Bean is made a top level class (and the class added to the jar) |
|
I'm going to move the bean class to its own class, which is nicer anymore and bypass the arquillian issue. |
Signed-off-by: Emily Jiang <[email protected]>
#145 refract the cts structure to bypass the class duplication
The test code in CdiOptionalInjectionTest results in two copies of the OptionalValuesBean class being in the war.
One copy (oddly) is placed in the war:/WEB-INF/classes
and another copy is in the jar:
This is very odd as the test code:
does not appear to explicitly add the bean class to the war:/WEB-INF/classes??
Weld does not like this at all:
I am no Arquillian expert but the error can be fixed by adding
to the jar construction. It would probably be better to have Arquillian config that prevented
the testcase having the class in the war's WEB-INF/classes but it does not do this as
currently written in my environment. Why?
The text was updated successfully, but these errors were encountered: