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
>
--
Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell 650-784-4123 - Sun Microsystems, Inc.