More clues:
My UNIX build from 11:30 AM (21565) -- works perfectly.
The problems are from my Windows machine...
Tim Quinn wrote:
> Byron Nevins wrote:
>>
>> Note that your checkin of pom.xml was revision 21573
>> My build used revision 21577
>> I.e. my checkout was after your changes.
> Yes, I know. The pom.xml as it is now in the svn repository is as it
> has been since July 18 (except for minor reformatting courtesy of
> NetBeans) so I think we are suffering from some other issue, although
> perhaps related to my check-in.
>
> Still trying to figure this out.
>
> - tim
>>
>> 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
>>>
>>
>
>
> ---------------------------------------------------------------------
> 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.