Hi,
Here is a summary of where i think we are:
1) Web container scanning does not scan for classes in jars of the ear
lib. We need to determine where this is a spec
limitation of a bug (see below). Also this may determine whether
classes in such libs can also be CDI managed, namely
whether such classes are visible to the BeanManager of the web
app.
2) There appears to be different deployment behaviors when NB 6.9
deploys an exploded ear and when asdmin is used to
deploy the ear. When deploying via NBs scanning works but there
are issues with CDI:
2.1) one issue seems to be related to when a directory contains
a space character;
SEVERE: Exception while loading the app
org.glassfish.deployment.common.DeploymentException: WELD-001201 Error
loading beans.xml java.io.IOException: Cannot open a foreign URL;
this.url=jar:file:/Users/paulsandoz/Downloads/glassfish-bugs%25202/
frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0-
SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar!/META-INF/beans.xml;
foreign.url=jar:file:/Users/paulsandoz/Downloads/glassfish-bugs%25202/
frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0-
SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar!/META-INF/beans.xml
2.2) if the directory does not contain a space the following
occurs:
SEVERE: Exception while loading the app
org.glassfish.deployment.common.DeploymentException: WELD-001409
Injection point has ambiguous dependencies. Injection point: field
ljnelson.frobnicator.jaxrs.FrobnicatorResource.junk; Qualifiers:
[@javax.enterprise.inject.Default()]; Possible dependencies:
[org.jboss.weld.bean-/Users/paulsandoz/Downloads/glassfish-bugs-2/
frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0-
SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar-ManagedBean-class
ljnelson.frobnicator.jaxrs.Junk, org.jboss.weld.bean-/Users/paulsandoz/
Downloads/glassfish-bugs-2/frobnicator/ear/target/gfdeploy/
ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/frobnicator-war-1.0-
SNAPSHOT_war/-ManagedBean-class ljnelson.frobnicator.jaxrs.Junk]
On Jun 16, 2010, at 7:25 PM, glassfish_at_javadesktop.org wrote:
>>> Yes. The problem is that this is for a big
>> application where, by
>>> design, we don't know what all the modules are for
>> a given .ear file
>>> until deployment time. So we're going to rely on
>> scanning, as I
>>> believe the specification implies we can.
>>
>> Yes.
>
> OK, so that bug is--without a doubt--the one referenced earlier in
> this thread.
>
Possibly :-) my expectation is the same as yours, but i am waiting on
information from those who know more about this area than i do.
>> Thanks! please CC me on logged bugs that is a better
>> way for me to
>> contribute. Tomorrow i can try and summarize things.
>
> Will do.
Thanks, i see you added me to the CC list.
> Email is I presume paul yourlastname at oracle dot com?
>
Not yet. As from the 1st July when France legally joins Oracle.
>>> I am currently planning on filing them against the
>> webservices
>>> component, although I don't see your name on the CC
>> list so that may
>>> not be the right component.
>>
>> I am the JAX-RS/Jersey person :-) i dived in because
>> JAX-RS/Jersey was
>> involved. But i think these issues we are
>> encountering are related to
>> GlassFish and not to JAX-RS/Jersey.
>
> OK; wasn't sure who in this mix was doing the scanning. If it's
> Glassfish's responsibility to do all the class scanning and to
> inform Jersey when it's found resource classes, then yeah. I was
> under the impression Jersey had the scanner?
It does as well, but it is not portable (it has been around before
scanning was defined in Servlet 3). Jersey's scanning is enabled by
choosing a particular implementation of Application that scans.
Paul.