Yes and no.

The right fix is that this input is added as one of the multiple inputs - via addInput, not as *the* input - which is what this proprty setting does.

You can use install element to invoke this addInput.

Sent from my iPod

On 29.1.2010, at 0:03, Brian Stansberry <brian.stansberry@redhat.com> wrote:

I've got what I think is the answer; am testing it now. We need to add this to the xml for WebAnnotationMetaDataDeployer:

<property name="allInputs">true</property>

Otherwise the addition of <property name="input">org.jboss.aop.asintegration.jboss5.AopMetaDataDeployerOutput</property> causes this to return false in DeployersImpl.isRelevant():

if (deployer.isAllInputs() == false)

{

// No attachment for the input type

Class<?> input = deployer.getInput();

if (input != null && unit.isAttachmentPresent(input) == false)

return false;

}

On 01/28/2010 03:40 PM, Brian Stansberry wrote:

Have a look at the AS trunk tomcat module's

o.j.web.tomcat.service.TomcatInjectionContainer class. The

TomcatInjectionContainer is instantiated as part of

o.j.w.t.service.deployer.TomcatDeployment's performDeployInternal(),

which itself is called as part of the start() phase of the mbean

representing the web module (webapp deployment is still mbean-based).

And, sorry to say, that about exhausts my knowledge on the subject. :(

I'll be poking around at this for the rest of the day as well.

On 01/28/2010 02:23 PM, Kabir Khan wrote:

Neither Flavia (I assume) nor I know anything about resource

injection, can somebody please explain a bit what is involved? Does it

use AOP?

On 28 Jan 2010, at 20:20, Ales Justin wrote:

Looks like @Resource injection doesn't kick in.

(running org.jboss.test.jpa.test.WebLibsJPAUnitTestCase)

@Resource

private UserTransaction ut;

protected void doGet(HttpServletRequest req, HttpServletResponse

resp) throws ServletException, IOException

{

try

{

ut.begin(); //<----- ut == null

21:15:28,125 ERROR

[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jpa-test].[TestServlet]]

Servlet.service() for servlet TestServlet threw exception:

java.lang.NullPointerException

at org.jboss.test.jpa.servlet.TestServlet.doGet(TestServlet.java:59)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

at

org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336)

at

org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)

at

org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)

at

org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

at

org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)

at

org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)

Flavia Rainone wrote:

Sure, I'll take a look.

On 01/28/2010 05:43 PM, Kabir Khan wrote:

Copying Flavia,

Flavia can you please take a look? I am tied up with another problem.

If there is something affecting the web stuff, a wild guess would

be the changing of the order of the deployers done here

http://fisheye.jboss.org/changelog/JBossAS/?cs=100000

However, without this fix AOP fails, since the

WarAnnotationMetaDataDeployer loads all the classes as mentioned on

dev list a day or two ago

On 28 Jan 2010, at 19:29, Brian Stansberry wrote:

Copying Ales and Scott Marlow, as an FYI. You all have been

chasing WebJPA failures, so thought you might be interested. We've

already determined that the JBW upgrade did not cause the new

failures; it was something in the #1 or #2 changesets below.

On 01/28/2010 12:22 PM, Brian Stansberry wrote:

Looks like we have some new failures in the AS testsuite:

http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16/529/testReport/

Changes between this run and the last run to completion are

listed in

the links below. Myself, Kabir, Carlo and Remy made changes;

please have

a look and fix ASAP. (Carlo I'm quite sure yours didn't break

anything

:) ).

The changes:

1)

http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16/529/changes

Note that before the #528 testsuite run hung and was killed, a

lot of

the new failures had appeared there; you'd have to scroll through

the

#528 console log to see exactly which.

2)

http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16/528/changes

3)

http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16/527/changes

4)

http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16/526/changes

This was the JBW update. I'll quickly check out trunk at this

revision

and run some of the newly failing tests to see if any of them go

back

this far.

--

Brian Stansberry

Lead, AS Clustering

JBoss by Red Hat

--

Brian Stansberry

Lead, AS Clustering

JBoss by Red Hat