I'm still seeing failures in the admin devtests
(
http://hudson.sfbay.sun.com/job/admin-devtests-v3.1/)
When deleting an instance, there is the following exception in the
server.log:
[#|2010-06-14T10:11:01.503-0500|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.config.support|_ThreadID=88;_ThreadName=Thread-1;|Exception
while deleting the configuration
com.sun.enterprise.config.serverbeans.Server :null
org.jvnet.hk2.config.TransactionFailure
at org.jvnet.hk2.config.ConfigSupport._apply(ConfigSupport.java:194)
at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:130)
at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:109)
at
org.glassfish.config.support.GenericDeleteCommand.execute(GenericDeleteCommand.java:124)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:324)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:339)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:965)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:94)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1106)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1095)
at
com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:367)
at
com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:113)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:802)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:705)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:986)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:178)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:526)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:507)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at
com.sun.enterprise.config.serverbeans.Domain$Duck.getClusterForInstance(Domain.java:670)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:900)
at org.jvnet.hk2.config.Dom.invoke(Dom.java:853)
at
org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:84)
at $Proxy17.getClusterForInstance(Unknown Source)
at
com.sun.enterprise.config.serverbeans.Server$DeleteDecorator.decorate(Server.java:491)
at
com.sun.enterprise.config.serverbeans.Server$DeleteDecorator.decorate(Server.java:474)
at
org.glassfish.config.support.GenericDeleteCommand$1.run(GenericDeleteCommand.java:142)
at org.jvnet.hk2.config.ConfigSupport$1.run(ConfigSupport.java:112)
at org.jvnet.hk2.config.ConfigSupport._apply(ConfigSupport.java:171)
... 28 more
|#]
This is from the most recent build from the continuous build.
Tom
On 6/11/2010 6:58 PM, Jerome Dochez wrote:
> Ok It should be fixed now, let me know if you see other issues.
>
> thx, jerome
>
> On 6/11/10 1:04 PM, Hong Zhang wrote:
>> Hi, Bill
>>>>
>>>> Yes, we have seen the same thing. Seems any DAS deployment with
>>>> --upload=true was broken and the clustering deployment was also broken
>>>> (there the --upload is always set to true). Jerome is helping to
>>>> investigate the cause right now...
>>>
>>> I added a quicklook test to test --upload=true, so that should be
>>> working in at least simple cases. If not, we need to fix the
>>> quicklook test!
>> Somehow when we run the whole QL tests from top, these tests are not
>> being run. When I went to that directory (web/helloworld) and ran all
>> tests there, I saw the same failure:
>>
>> deploy-upload-v3-impl:
>> [echo] deploying hellojsp.war with --upload
>>
>> deploy-upload-v3-impl-unix:
>> [exec] remote failure: Unknown plain text format. Response from
>> the server: {0}
>> [exec] Command deploy failed.
>> [exec] Result: 1
>>
>> Ming: can you take a look to see why these deploy-upload tests were
>> not being run if we ran the tests from the top?
>>
>> Thanks,
>>
>> - Hong
>>
>> ---------------------------------------------------------------------
>> 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
>