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
>>
>