Note that your checkin of pom.xml was revision 21573
My build used revision 21577
I.e. my checkout was after your changes.
My guess is that the fix did not work.
Tim Quinn wrote:
> Byron,
>
> Read the other mail thread on this list starting with Jane's initial
> "[v3] unable to deploy" header. It's the same problem and I have
> fixed this. If you refresh the web/web-glue/pom.xml to get the
> correct version and rebuild web/web-glue (and distribution/web and
> reinstall the web distribution if that's how you test) then it should
> be fine.
>
> - tim
>
> Byron Nevins wrote:
>> I did a total rebuild today, ~~ 2:30 PM
>> I deleted my local maven repository, checked out HK2 and V3 from
>> scratch.
>> It built OK. I installed the web distro and deployed a very simple
>> war file. Kaboom.
>>
>> Any idea what this means?
>>
>> SEVERE: Exception in command execution :
>> com.sun.enterprise.module.ResolveError: Failed to start
>> org.glassfish.web.web-glue(Web Cont
>> ainer glue code):10.0.0.SNAPSHOT
>> com.sun.enterprise.module.ResolveError: Failed to start
>> org.glassfish.web.web-glue(Web Container glue code):10.0.0.SNAPSHOT
>> at
>> org.jvnet.hk2.osgiadapter.OSGiModuleImpl.resolve(OSGiModuleImpl.java:113)
>>
>> at
>> org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:122)
>> at
>> org.jvnet.hk2.osgiadapter.OSGiModuleImpl$1$1.loadClass(OSGiModuleImpl.java:257)
>>
>> at
>> com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:91)
>> at
>> com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:106)
>> at
>> com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
>>
>> at
>> org.glassfish.internal.data.ContainerInfo.getContainer(ContainerInfo.java:75)
>>
>> at
>> com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:795)
>>
>> at
>> com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:432)
>>
>> at
>> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:268)
>>
>> at
>> com.sun.enterprise.v3.deployment.DeployCommand.execute(DeployCommand.java:270)
>>
>> at
>> com.sun.enterprise.v3.admin.CommandRunner.doCommand(CommandRunner.java:286)
>>
>> at
>> com.sun.enterprise.v3.admin.CommandRunner.doCommand(CommandRunner.java:114)
>>
>> at
>> com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:239)
>>
>> at
>> com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:156)
>> at
>> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:148)
>>
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:621)
>>
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:552)
>>
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:800)
>>
>> at
>> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:152)
>>
>> at
>> com.sun.enterprise.v3.services.impl.HttpProtocolFilter.execute(HttpProtocolFilter.java:82)
>>
>> at
>> com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:70)
>>
>> at
>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
>>
>> at
>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
>>
>> at
>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>>
>> at
>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
>>
>> at
>> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
>> Caused by: org.osgi.framework.BundleException: Unresolved package in
>> bundle 12: package; (package=org.apache.tools.ant.types)
>> at
>> org.apache.felix.framework.Felix._resolveBundle(Felix.java:1728)
>> at org.apache.felix.framework.Felix._startBundle(Felix.java:1591)
>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1544)
>> at
>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:371)
>> at
>> org.jvnet.hk2.osgiadapter.OSGiModuleImpl.resolve(OSGiModuleImpl.java:110)
>>
>> ... 26 more
>>
>>
>>
>> Sahoo wrote:
>>> I have put back changes that allows us to have similar behavior like
>>> GF v1 or v2 with regards to application class loading. Given below
>>> is the relevant portion of my check-in comments [1]
>>>
>>> As discussed in the OSGi/V3 one-pager, application class loader
>>> in v3 behaves very similarly to v2, with the exception that not all
>>> server
>>> classes are visible. Only classes exported by implementation bundles
>>> for
>>> public use are available to application class loader. The hierarchy
>>> looks like
>>> this:
>>>
>>> archive class loader [H]
>>> -> Modules class loader [G]
>>> -> applib class loader [F]
>>> -> connector class loader [E]
>>> -> common class loader [D]
>>> -> public API class loader [C]
>>> -> extension class loader [B]
>>> -> null (a.k.a. bootstrap class loader) [A]
>>>
>>> Description of each element of the above delegation chain is given
>>> below:
>>>
>>> A. null: This is the bootstrap class loader of JRE. loads classes
>>> from rt.jar.
>>>
>>> B. extension class loader: It is JRE supplied class loader. Takes
>>> care of
>>> installed extensions (i.e. java.ext.dirs).
>>>
>>> C. public API class loader: It makes available all classes specifically
>>> exported by OSGi bundles installed in the runtime. This typically
>>> includes,
>>> but not limited to, Java EE APIs and other GlassFish APIs that we want
>>> applications to have access to. Currently, our OSGi bundles pretty
>>> much expose
>>> every package for public use. This should be fixed as described in
>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=5385.
>>> This class loader is implemented as a class loader of a OSGi bundle
>>> which
>>> has following import statement:
>>> DynamicImport-Package: *
>>>
>>> D. common class loader: This is responsible for making available
>>> libraries and
>>> classes installed in following places (in the order mentioned below):
>>> domain/lib/, domain/classes/, domain/lib/
>>>
>>> E. connector class loader: This is responsible for making standalone
>>> connectors
>>> available to deployed applications. It is written such that we can
>>> easily
>>> implement the new recommendation of Java EE 6 spec, which says a
>>> container
>>> should only make those standalone RARs available to applications that
>>> applications specifically depend on.
>>>
>>> F. applib class loader: Respondible for taking care of scoped
>>> libraries. These
>>> are libraries that an application depends on by specifying
>>> --libraries option
>>> during deployment.
>>>
>>> G: Modules class loader: This has visibility to all OSGi bundles that
>>> an application specifically requests access to either using
>>> HK2-Import-Bundles
>>> header or GlassFish-Requires-Service headers in manifest.mf. I strongly
>>> discourage using those techniques.
>>>
>>> H. archive class loader: Responsible for loading classes from
>>> application
>>> archive.
>>>
>>> This hierarchy is pretty similar to what we have in v2:
>>> http://docs.sun.com/app/docs/doc/819-3659/beadf?a=view
>>>
>>> To get hold of various elements of the hierarchy, a new API has been
>>> introduced in internal-api module called ClassLoaderHierarchy.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> [1]
>>> http://fisheye4.atlassian.com/changelog/glassfish-svn/trunk/v3?cs=21565
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
--
Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell 650-784-4123 - Sun Microsystems, Inc.