[GLASSFISH-21530] What is GRIZZLY0013? Created: 24/Mar/16  Updated: 24/Mar/16

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: t.shimada Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1
Grizzly 2.3.15
Oracle JDK 1.8.0_61



 Description   

Hello I'm TOSHIKAZU. Our Glassfish have problem.
Please teach me how to fix or workaround.

Overview
========
In my client & server of commercially operating of our system has came up with the message of [WARNING][Error] in Glassfish's server.log as problem.
We don't know why has occuerd these problem from our glassfish server.

the following message:
■a part of server.log
---------------------------------------------------
[YYYY-MM-DDT18:51:02.575+0900] [glassfish 4.1] [WARNING] [] [org.glassfish.grizzly.filterchain.DefaultFilterChain] [tid: _ThreadID=132 _ThreadName=BidRateTimer] [timeMillis: 1458553862575] [levelValue: 900] [[
GRIZZLY0013: Exception during FilterChain execution
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:275)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.fill(TCPNIOUtils.java:200)
at org.glassfish.grizzly.nio.transport.TCPNIOUtils.writeCompositeBuffer(TCPNIOUtils.java:81)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:112)
at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:91)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:261)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:170)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:70)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleWrite(TCPNIOTransportFilter.java:126)
at org.glassfish.grizzly.filterchain.TransportFilter.handleWrite(TransportFilter.java:191)
at org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:848)
at org.glassfish.grizzly.filterchain.FilterChainContext.write(FilterChainContext.java:817)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBuffer(OutputBuffer.java:1024)
at org.glassfish.grizzly.http.io.OutputBuffer.flushBinaryBuffers(OutputBuffer.java:1011)
at org.glassfish.grizzly.http.io.OutputBuffer.flushAllBuffers(OutputBuffer.java:982)
at org.glassfish.grizzly.http.io.OutputBuffer.flush(OutputBuffer.java:737)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:291)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:275)
at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:175)
at jp.co.fractal.fx.webpublisher.handler.EventHandler.onEvent(EventHandler.java:88)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify0(DefaultNotificationHandler.java:117)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify(DefaultNotificationHandler.java:93)
at org.glassfish.grizzly.comet.DefaultNotificationHandler.notify(DefaultNotificationHandler.java:83)
at org.glassfish.grizzly.comet.CometContext.notify(CometContext.java:437)
at jp.co.my.do.publisher.management.CometManagement.notifyPrd(CometManagement.java:115)
at jp.co.my.do.publisher.management.timertask.DataPushTask.eventNotify(DataPushTask.java:131)
at jp.co.my.do.publisher.management.timertask.DtatPushTask.run(DataPushTask.java:99)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
]]
---------------------------------------------------

Symptom
=======
#1 When Occuer, Many sessions from rich client will be disconnected to Glassfish server.

#2 Since we will be unbale to connect to server from rich clients every one.

#3 When we tried to reboot the domain(process) of Glassfish, But it was not fix.
In fact the domain(process) couldn't be started by restart command.

#4 Stop its Domain -> Reboot OS -> Start its Domain
Then We try to do the bellow of methods, We can recover our system. Since the rich clients can connect to server as usual.

Our environments
=====
Glassfish 4.1
Grizzly 2.3.15
Oracle JDK 1.8.0_61

Question 1
=====
Do you know why come up this [WARNING][Error]?
What happen has this [WARNING][Error] our glassfish?

Question 2
=====
Do you know how to workaround?

Question 3
=====
Do you know how to fix?

Question 4
=====
Do you has experienced improving this problem as case example?

Question 5
=====
How should we invest when we has this problem?

Best Regards.






[GLASSFISH-21493] JDK9 - REFERENCES TO JDK INTERNAL API IN com.sun.xml.ws.util.xml.XmlUtil Created: 25/Jan/16  Updated: 01/Feb/16

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Arindam Bandyopadhyay Assignee: Arindam Bandyopadhyay
Resolution: Unresolved Votes: 0
Labels: jdk9-int
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks GLASSFISH-21441 Umbrella Issue for Glassfish testing ... Open

 Description   

There is a reference to jdk internal api in com.sun.xml.ws.util.xml.XmlUtil. We are getting the following two exception.
----------------------------------------------
WSSERVLET11: failed to parse runtime descriptor: java.lang.IllegalAccessError: superclass access check failed: class com.sun.xml.ws.util.xml.XmlUtil$3 (in module: Unnamed Module) cannot access class com.sun.org.apache.xml.internal.resolver.CatalogManager (in module: java.xml), com.sun.org.apache.xml.internal.resolver is not exported to Unnamed Module
java.lang.IllegalAccessError: superclass access check failed: class com.sun.xml.ws.util.xml.XmlUtil$3 (in module: Unnamed Module) cannot access class com.sun.org.apache.xml.internal.resolver.CatalogManager (in module: java.xml), com.sun.org.apache.xml.internal.resolver is not exported to Unnamed Module
at java.lang.ClassLoader.defineClass1(java.base@9.0/Native Method)
at java.lang.ClassLoader.defineClass(java.base@9.0/ClassLoader.java:925)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2279)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1501)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
at java.lang.ClassLoader.loadClass(java.base@9.0/ClassLoader.java:373)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.getXMLInputFactory(XMLStreamReaderFactory.java:131)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.access$000(XMLStreamReaderFactory.java:77)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory$1.initialValue(XMLStreamReaderFactory.java:92)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory$1.initialValue(XMLStreamReaderFactory.java:87)
at com.sun.xml.ws.api.streaming.ContextClassloaderLocal.createNewInstance(ContextClassloaderLocal.java:76)
at com.sun.xml.ws.api.streaming.ContextClassloaderLocal.get(ContextClassloaderLocal.java:62)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.get(XMLStreamReaderFactory.java:152)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.create(XMLStreamReaderFactory.java:175)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:176)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:131)
at com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer.onStartup(WSServletContainerInitializer.java:65)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:6062)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:774)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5960)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(java.base@9.0/Native Method)
at javax.security.auth.Subject.doAs(java.base@9.0/Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:531)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(java.base@9.0/Thread.java:747)

------------------------------------------------
WSSERVLET11: failed to parse runtime descriptor: java.lang.IllegalAccessError: class com.sun.xml.ws.util.xml.XmlUtil (in module: Unnamed Module) cannot access class com.sun.org.apache.xml.internal.resolver.tools.CatalogResolver (in module: java.xml), com.sun.org.apache.xml.internal.resolver.tools is not exported to Unnamed Module
java.lang.IllegalAccessError: class com.sun.xml.ws.util.xml.XmlUtil (in module: Unnamed Module) cannot access class com.sun.org.apache.xml.internal.resolver.tools.CatalogResolver (in module: java.xml), com.sun.org.apache.xml.internal.resolver.tools is not exported to Unnamed Module
at com.sun.xml.ws.util.xml.XmlUtil.workaroundCatalogResolver(XmlUtil.java:361)
at com.sun.xml.ws.util.xml.XmlUtil.createEntityResolver(XmlUtil.java:307)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.createEntityResolver(DeploymentDescriptorParser.java:450)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:303)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:179)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:131)
at com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer.onStartup(WSServletContainerInitializer.java:65)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:6062)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:774)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5960)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(java.base@9.0/Native Method)
at javax.security.auth.Subject.doAs(java.base@9.0/Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(java.base@9.0/Native Method)
at javax.security.auth.Subject.doAs(java.base@9.0/Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:531)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)

at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(java.base@9.0/Thread.java:747)
---------------------------------------------------------------------------------
In com.sun.xml.ws.util.xml.XmlUtil we have the reference of com.sun.org.apache.xml.internal.resolver.CatalogManager and com.sun.org.apache.xml.internal.resolver.tools.CatalogResolver which are JDK internal api . So we are getting the exception .

com.sun.xml.ws.util.xml.XmlUtil is a maven dependency
<groupId>org.glassfish.metro</groupId>
<artifactId>webservices-osgi</artifactId>
So we need the org.glassfish.metro team to fix it .



 Comments   
Comment by Arindam Bandyopadhyay [ 25/Jan/16 ]

As a work around please add the following java option -XaddExports:java.xml/com.sun.org.apache.xml.internal.resolver=ALLUNNAMED,java.xml/com.sun.org.apache.xml.internal.resolver.tools=ALL-UNNAMED





[GLASSFISH-21392] Web-service endpoint is not available for the deployed EJB application Created: 23/Jul/15  Updated: 14/Sep/15  Due: 14/Sep/15

Status: In Progress
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gregn123 Assignee: Debayan_Gupta
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 1 day
Time Spent: 3 days
Original Estimate: 4 days
Environment:

All



 Description   

A colleague of mine originally reported this bug for Glassfish 4.0 here:

https://java.net/jira/browse/GLASSFISH-20661

Although I've recently updated that issue, it's doubtful that it will ever be looked at again, based on the activity of that issue's assignee(s), and the fact that it's marked as affecting version 4.0.

This bug still exists in Glassfish 4.1, so I'm creating a new issue for GF 4.1 here...

I have clarified the problem below:

Scenario:

JAR file "ws_ejb_ok.jar" contains a Stateless session bean implementation, annotated by @Stateless, that exposes a web-service endpoint by using a @WebService annotation.
The "name" attribute of the @Stateless annotation (value: "HelloEJBa") matches the "<ejb-name>" specified in the ejb-jar.xml descriptor.
Note that the <ejb-class> specified in the ejb-jar.xml descriptor matches the stateless session-bean implementation class.
Result: the JAR file deploys OK, the session bean and web-service endpoint are available and working. There is a message in the server.log file "EJB Endpoint deployed ws_ejb_ok listening at address at http://...", confirming that the endpoint is available.

JAR file "ws_ejb_ng.jar" is almost exactly the same as JAR file "ws_ejb_ok.jar", except that the value of the "name" attribute of the @Stateless annotation (value "HelloEJBa") DOES NOT MATCH the "<ejb-name>" specified in the ejb-jar.xml descriptor (value "HelloEJBb").
Result: the JAR file deploys OK (and no errors in the server.log), and two stateless session-beans are deployed (which I believe is correct because they have different names), BUT the web-service endpoint IS NOT AVAILABLE.
The expected message "EJB Endpoint deployed ws_ejb_ng listening at address at http://..." DOES NOT APPEAR in the server.log file.
Effectively the web-service is disabled by defining another session bean in the ejb-jar.xml descriptor that has the same class but different ejb-name.

I have fully explained the bug and it's cause, provided sample apps that illustrate and reproduce the bug, and provided a proposed patch for Glassfish 4.1 (source patch + corresponding binary) here:

https://github.com/gregn123/GLASSFISH-20661

Please see the README.txt file in the above GitHub repository for more details.






[GLASSFISH-21381] war with web service not deploying correctly Created: 26/Jun/15  Updated: 11/Sep/15  Resolved: 21/Aug/15

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: Vinay Vishal
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ab28a7f03c159ddc1af43e792c46d4d282d3759.war     Java Archive File src.jar    
Issue Links:
Duplicate
is duplicated by GLASSFISH-20740 @WebServiceRef annotation (at least i... Resolved

 Description   

The following cdi test application passes deployment but produces the following exceptions. If it was successful you should be able to execute this url:

http://localhost:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/TestFilter2?test=wsresource

and get back this to the browser:

Filter init: true

The same application deploys and runs successfully on WLS. I have attached both the war and the source code for the application.

This bug is preventing us from passing the cdi tck 1.2.5.Final.

[#|2015-06-26T14:47:45.784-0400|WARNING|glassfish 4.1|javax.enterprise.webservices|_ThreadID=56;_ThreadName=AutoDeployer;_TimeMillis=1435344465784;_LevelValue=900;_MessageID=AS-WSJSR109IMPL-00050;|
Following exception was thrown:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.glassfish.webservices.WebServiceReferenceManagerImpl.initiateInstance(WebServiceReferenceManagerImpl.java:319)
at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:142)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:954)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:745)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:159)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:636)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:507)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:170)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:165)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:336)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:263)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:485)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:439)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:336)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:1007)
at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:2143)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:131)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5329)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5974)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:597)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:484)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:412)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:403)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: javax.xml.ws.WebServiceException: Failed to access the WSDL at: http://JJ-TP420:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL. It failed with:
http://JJ-TP420:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL.
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:265)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:246)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:209)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:178)
at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:364)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:322)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:231)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:212)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:208)
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:119)
at javax.xml.ws.Service.<init>(Service.java:92)
at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TranslatorService.<init>(TranslatorService.java:58)
... 66 more
Caused by: java.io.FileNotFoundException: http://JJ-TP420:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1625)
at java.net.URL.openStream(URL.java:1037)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.createReader(RuntimeWSDLParser.java:999)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(RuntimeWSDLParser.java:400)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231)
... 76 more

#]

[#|2015-06-26T14:47:45.789-0400|SEVERE|glassfish 4.1|javax.enterprise.web|_ThreadID=56;_ThreadName=AutoDeployer;_TimeMillis=1435344465789;_LevelValue=1000;|
WebModule[/ab28a7f03c159ddc1af43e792c46d4d282d3759]Exception starting filter org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2
java.lang.InstantiationException
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:135)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5329)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5974)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:597)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:484)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:412)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:403)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:352)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:1007)
at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:2143)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:131)
... 36 more
Caused by: java.lang.IllegalStateException: Exception attempting to inject Env-Prop: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField@Field-Injectable Resource. Class name = org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2 Field name=translatorField@javax.jws.WebServiceRef@@@ into class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2: Lookup failed for 'java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:175)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:336)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:263)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:485)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:439)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:336)
... 40 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Env-Prop: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField@Field-Injectable Resource. Class name = org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2 Field name=translatorField@javax.jws.WebServiceRef@@@ into class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2: Lookup failed for 'java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:740)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:507)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:170)
at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:165)
... 48 more
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NamingException [Root exception is java.lang.reflect.InvocationTargetException]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:636)
... 51 more
Caused by: javax.naming.NamingException [Root exception is java.lang.reflect.InvocationTargetException]
at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:271)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:954)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:745)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:159)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
... 55 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.glassfish.webservices.WebServiceReferenceManagerImpl.initiateInstance(WebServiceReferenceManagerImpl.java:319)
at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:142)
... 60 more
Caused by: javax.xml.ws.WebServiceException: Failed to access the WSDL at: http://JJ-TP420:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL. It failed with:
http://JJ-TP420:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL.
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:265)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:246)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:209)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:178)
at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:364)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:322)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:231)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:212)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:208)
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:119)
at javax.xml.ws.Service.<init>(Service.java:92)
at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TranslatorService.<init>(TranslatorService.java:58)
... 66 more
Caused by: java.io.FileNotFoundException: http://JJ-TP420:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1625)
at java.net.URL.openStream(URL.java:1037)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.createReader(RuntimeWSDLParser.java:999)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(RuntimeWSDLParser.java:400)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231)
... 76 more

#]


 Comments   
Comment by payara_steve [ 07/Jul/15 ]

The InvocationTargetException is actually also thrown during deployment but the application still deploys successfully.

The underlying exception during deployment is WebServiceException Failed to access the WSDL at: http://ubuntu:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL. It failed with: http://ubuntu:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL.

The underlying exception is FileNotFoundException http://ubuntu:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL[#|2015-07-07T07:28:36.291+0100|SEVERE|Payara 4.1|javax.enterprise.web|_ThreadID=45;_ThreadName=admin-listener(4);_TimeMillis=1436250516291;_LevelValue=1000;|

  WebModule[/ab28a7f03c159ddc1af43e792c46d4d282d3759]Exception starting filter org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2
java.lang.InstantiationException
        at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:135)
        at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5331)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:5974)
        at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
        at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
        at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
        at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
        at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
        at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
        at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
        at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:360)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:360)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
        at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:253)
        at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:231)
        at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:275)
        at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:136)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
        at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:308)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:291)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1140)
        at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:375)
        at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:316)
        at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
        at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
        at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
        at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
        at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
        at java.lang.Thread.run(Thread.java:745)
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2
        at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:352)
        at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:1007)
        at com.sun.enterprise.web.WebModule.createFilterInstance(WebModule.java:2143)
        at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264)
        at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:131)
        ... 76 more
Caused by: java.lang.IllegalStateException: Exception attempting to inject Env-Prop: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField@Field-Injectable Resource. Class name = org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2 Field name=translatorField@javax.jws.WebServiceRef@@@ into class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2: Lookup failed for 'java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
        at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:175)
        at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
        at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
        at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
        at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:336)
        at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:263)
        at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:486)
        at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:439)
        at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:336)
        ... 80 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Env-Prop: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField@Field-Injectable Resource. Class name = org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2 Field name=translatorField@javax.jws.WebServiceRef@@@ into class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2: Lookup failed for 'java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
        at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:740)
        at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:507)
        at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:170)
        at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:165)
        ... 88 more
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException [Root exception is java.lang.reflect.InvocationTargetException]]
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
        at javax.naming.InitialContext.lookup(InitialContext.java:417)
        at javax.naming.InitialContext.lookup(InitialContext.java:417)
        at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:638)
        ... 91 more
Caused by: javax.naming.NamingException [Root exception is java.lang.reflect.InvocationTargetException]
        at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:271)
        at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:954)
        at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:745)
        at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
        at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:159)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
        ... 95 more
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
        at org.glassfish.webservices.WebServiceReferenceManagerImpl.initiateInstance(WebServiceReferenceManagerImpl.java:320)
        at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:142)
        ... 100 more
Caused by: javax.xml.ws.WebServiceException: Failed to access the WSDL at: http://ubuntu:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL. It failed with: 
        http://ubuntu:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL.
        at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:265)
        at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:246)
        at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:209)
        at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:178)
        at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:363)
        at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:321)
        at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:230)
        at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:211)
        at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:207)
        at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:114)
        at javax.xml.ws.Service.<init>(Service.java:92)
        at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TranslatorService.<init>(TranslatorService.java:58)
        ... 106 more
Caused by: java.io.FileNotFoundException: http://ubuntu:8080/ab28a7f03c159ddc1af43e792c46d4d282d3759/Translator/__container$publishing$subctx/null?WSDL
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1835)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440)
        at java.net.URL.openStream(URL.java:1038)
        at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.createReader(RuntimeWSDLParser.java:999)
        at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(RuntimeWSDLParser.java:400)
        at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231)
        ... 116 more
|#]
Comment by payara_steve [ 07/Jul/15 ]

The message

[#|2015-07-07T07:21:31.864+0100|INFO|Payara 4.1|org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TranslatorService|_ThreadID=45;_ThreadName=admin-listener(4);_TimeMillis=1436250091864;_LevelValue=800;|
  Can not initialize the default wsdl from WEB-INF/Translator.wsdl|#]

Is also logged earlier in the deployment

Comment by Vinay Vishal [ 07/Jul/15 ]

Thanks Steve. Will soon start working on it.

Comment by payara_steve [ 07/Jul/15 ]

Looking at

    static {
        URL url = null;
        try {
            url = new URL("");
        } catch (MalformedURLException e) {
            java.util.logging.Logger.getLogger(TranslatorService.class.getName())
                .log(java.util.logging.Level.INFO, 
                     "Can not initialize the default wsdl from {0}", "WEB-INF/Translator.wsdl");
        }
        WSDL_LOCATION = url;
    }

WSDL_LOCATION is possibly being set to null due to the MalformedURLException in TranslatorService.java

Comment by Vinay Vishal [ 10/Jul/15 ]

The issue here is, in case of Filters, filters gets loaded at the time of deployment itself. When @WebServiceRef annotation is being processed, lookup is performed in JNDI based on the variable "translatorField" defined in org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2 Filter class in the web-app in the question. So during lookup of "java:comp/env/org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TestFilter2/translatorField" node in JNDI tree, it fails to get the org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TranslatorService instance because instantiation fails due to unavailability of web service wsdl at http://localhost/test/Translator/__container$publishing$subctx/null?WSDL" at this point in deployment.
Ignoring NamingException results in successful load of Filter class itself. Same problem will occur even for servlets when loadOnStartup is specified for servlet too.

This basically is a design issue and currently being discussed internally. Will further update when we have a possible fix for this problem.

Comment by Shing Wai Chan [ 03/Aug/15 ]

The "Translator" mapping data is added "after" the above invocation of the url as follows:
at org.glassfish.grizzly.http.server.util.Mapper.addWrapper(Mapper.java:478)
at org.glassfish.internal.grizzly.ContextMapper.addWrapper(ContextMapper.java:81)
at com.sun.enterprise.web.connector.MapperListener.registerWrapper(MapperListener.java:555)
at com.sun.enterprise.web.connector.MapperListener.handleNotification(MapperListener.java:308)
at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:275)
at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:352)
at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:337)
at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:248)
at org.apache.catalina.core.StandardWrapper.sendNotification(StandardWrapper.java:2280)
at org.apache.catalina.core.StandardWrapper.registerJMX(StandardWrapper.java:2246)
at org.apache.catalina.core.StandardContext.registerJMX(StandardContext.java:7013)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5999)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)

Comment by Vinay Vishal [ 21/Aug/15 ]

Sending appserver/webservices/jsr109-impl/src/main/java/org/glassfish/webservices/LogUtils.java
Sending appserver/webservices/jsr109-impl/src/main/java/org/glassfish/webservices/WebServiceReferenceManagerImpl.java
Transmitting file data ..
Committed revision 64068.

Comment by Vinay Vishal [ 21/Aug/15 ]

Code has been reviewed by Lukas Jungmann and Bill Shannon. Checked-in post approval from Bill.
Tests Run:
Quick Look - No failure
Web Dev tests - Out of 720 tests, 715 passed , 5 failed. These tests were failing locally even without this change.
Full CTS planned to be run.





[GLASSFISH-21303] A class annotated with both WebService and WebServlet causes deployment failure. Created: 09/Feb/15  Updated: 28/Jul/15

Status: Reopened
Project: glassfish
Component/s: web_container, web_services
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: Vinay Vishal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A class in a war with the following annotations causes this exception upon deployment.
Caused by: java.io.IOException: Server returned HTTP response code: 405 for URL: http://localhost:8080/RequestContext/translator?wsdl

If I make the class extend HttpServlet I get a different exception:

Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: Premature end of file.
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:601)

Here is the class:

@WebServlet(loadOnStartup = 1, name = "Translator", urlPatterns = "/translator")
@WebService(endpointInterface = "org.jboss.cdi.tck.tests.context.request.ws.Translator", serviceName = "Translator")
public class TranslatorEndpoint implements Translator {}

I will attach a sample war shortly.



 Comments   
Comment by Vinay Vishal [ 30/Jun/15 ]

Can you please attach sample war?

Comment by Vinay Vishal [ 01/Jul/15 ]

I wrote a sample application with the same annotations as specified in the bug description and I am getting following exception:

Servlet [TranslatorEndpoint] and Servlet [org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TranslatorEndpoint] have the same url pattern: [/Translator]. Related annotation information: annotation [@javax.jws.WebService(wsdlLocation=, endpointInterface=org.jboss.cdi.tck.tests.lookup.injection.non.contextual.Translator, targetNamespace=, portName=, name=, serviceName=Translator)] on annotated element [class org.jboss.cdi.tck.tests.lookup.injection.non.contextual.TranslatorEndpoint] of type [TYPE].

This is happening because there already exist a class with the same name as TranslatorEndPoint having same url pattern as specified in the bug.

Here is the sample class written to reproduce this issue:

TranslatorEndPoint.java
@WebServlet(loadOnStartup = 1, name = "Translator", urlPatterns = "/translator")
@WebService(endpointInterface = "org.jboss.cdi.tck.tests.context.request.ws.Translator", serviceName = "Translator")
public class TranslatorEndpoint implements Translator {

@WebMethod
public String translate(){

System.out.println("translate");
return "translate";
}

maven dependency:

cdi-tck-impl / version 1.2.5.Final

Please provide the sample war and error log from server.log file to be able to reproduce and debug this issue.

Comment by jjsnyder83 [ 01/Jul/15 ]

It appears that this has been fixed somehow. The cdi tck test that was failing due to this is now passing. Perhaps this was fixed by some other change. In any case I cannot reproduce the issue anymore.

Comment by Vinay Vishal [ 02/Jul/15 ]

Ok, thanks for the update. Please open a new bug or re-open the same if you happen to see this issue again.

Comment by tremes [ 27/Jul/15 ]

I can still reproduce this bug (at least partially) with CDI TCK. and glassfish-4.1-b13-03_18_2015. Unfortunately I cannot attach anything to this issue.

Caused by: java.io.IOException: Server returned HTTP response code: 405 for URL: http://localhost:8080/2a1f6f6da8c03555e9ff54777d4beaf8489c3d7/translator?wsdl
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1839)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440)
	at java.net.URL.openStream(URL.java:1038)
	at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.createReader(RuntimeWSDLParser.java:984)
	at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(RuntimeWSDLParser.java:385)
	at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:216)
Comment by jjsnyder83 [ 27/Jul/15 ]

You need to use a relatively new build. the one you're using is from 3/18/2015 which apparently doesn't contain the fixes.

Comment by tremes [ 28/Jul/15 ]

Sorry but it doesn't matter. I copy/paste just bad version. In fact I was using glassfish-4.1-b14-07_26_2015. The TCK test is passing now but when you remove servlet definition from web.xml and you use @WebServlet then you will see the error above.

Comment by jjsnyder83 [ 28/Jul/15 ]

If you feel this is still a bug please reopen the issue or enter a new one and assign the component to web_container and web_services. This is not a CDI issue.

Comment by tremes [ 28/Jul/15 ]

Yes it's not a CDI issue. Unfortunately I don't have permissions to reopen it.

Comment by jjsnyder83 [ 28/Jul/15 ]

Ok I reopened it for you.





[GLASSFISH-21302] Wrong context path with webservice stateless Created: 09/Feb/15  Updated: 09/Feb/15

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janario Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When I have a webservice stateless it isn't available in the application context.

e.g.

@WebService @Stateless //It will be available in http://localhost:8080/StatelessWebServiceService. Not with the application context
public class StatelessWebService {
public boolean executeTest()

{ return true;}

}

Without @Stateless it works right (http://localhost:8080/as-test-suite/StatelessWebServiceService)
@WebService
public class StatelessWebService

{ ... }




[GLASSFISH-21268] JAX-WS servlet-mapping in web.xml Created: 10/Dec/14  Updated: 10/Dec/14

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: blasss Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Basically a JAX-WS web service can be provided as servlet-based service implementation. In this case the container scans a web application for all classes annotated as web service.

Using the @WebService annotation a serviceName can be specified. This service name is used to make up the path to the web service (url-pattern=/<serviceName>).
If an additional web.xml file is supplied in the WAR the url-pattern of the servlet-mapping is to be considered as the path to the web service.

This is based on JSR 109 http://download.oracle.com/otn-pub/jcp/websvcs-1_4-mrel3-eval-spec/websvcs-1_4-fr.pdf stating in 5.3.2.1:

Following default mapping rules apply for Web modules that contain Servlet based endpoints that use this annotation but do not package a web.xml or a partial web.xml:

  • fully qualified name of the Service Implementation Bean class maps to <servlet-name> element in web.xml.
  • fully qualified name of the Service Implementation Bean class maps to <servlet-class> element in web.xml (also specified in section 7.1.2)
  • serviceName attribute of javax.jws.WebService annotation prefixed with "/" maps to <url-pattern> element in web.xml. If the serviceName attribute in javax.jws.WebService annotation is not specified, then the default value as specified in JSR-181 specification is used.

and in 71.2

Servlet Mapping. A developer may optionally specify a servlet-mapping, in the web.xml deployment descriptor, for a JAX-RPC or JAX-WS Service Endpoint. No more than one servlet-mapping may be specified for a servlet that is linked to by a port-component. The url-pattern of the servlet-mapping must be an exact match pattern (i.e. it must not contain an asterisk (“*”)).

For the attached example WAR this should yield a web service with the following path (expected behaviour):
http://<host>/<web_application>/de.testjsr109.ServiceWithNameURLPattern

Unfortunately Glassfish only takes the serviceName-Attribute into consideration and provides the web service at (actuial behaviour):
http://<host>/<web_application>/ServiceWithNameAnnotation



 Comments   
Comment by blasss [ 10/Dec/14 ]

No File attaching....

ServiceWithName.java
package de.testjsr109;

import javax.jws.WebService;

@WebService(serviceName="ServiceWithNameAnnotation")
public class ServiceWithName
{
    public String sayHello(String name)
    {
        return "Hello " + name;
    }
}
web.xml
<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    version="2.5">
    <servlet><servlet-name>JAXWSServiceWithName</servlet-name><servlet-class>de.testjsr109.ServiceWithName</servlet-class></servlet>
    <servlet-mapping><servlet-name>JAXWSServiceWithName</servlet-name><url-pattern>/de.testjsr109.ServiceWithNameURLPattern</url-pattern></servlet-mapping>
</web-app>




[GLASSFISH-21201] WebServicesDeployer failing with WCF webservice Created: 16/Sep/14  Updated: 16/Sep/14

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: angelofranco Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP



 Description   

I'm migration a Java application fromTomcat to Glassfish. I'm able to build correctly from Eclipse and generate the war file. When I try to depoy the application in GlassFish, I receive the error below in the log file.

I ran a debugger and I found that the wsdlLocation in one of my classes is being downloaded by GlassFish and it is trying to save it in this folder:

C:\glassfish4\glassfish\domains\domain1\generated\xml\SCE3\WEB-INF\wsdl\EnvioLoteXML.svc?wsdl

This is what's triggering the exception, since windows can't save files with special characters (in this case, the question mark).

This webservice is provided by a third party and it was developed in WCF. I'm afraid we can't get change the question mark from the wsdl URL.

From reading similar issues, I figured I could save the wsdl file in the project and reference it, instead of referencing the URL. Is this the only option available?

[2014-09-16T07:14:25.319-0500] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=36 _ThreadName=admin-listener(3)] [timeMillis: 1410869665319] [levelValue: 1000] [[
Exception while preparing the app : java.io.IOException: The filename, directory name, or volume label syntax is incorrect – The filename, directory name, or volume label syntax is incorrect
org.glassfish.deployment.common.DeploymentException: java.io.IOException: The filename, directory name, or volume label syntax is incorrect – The filename, directory name, or volume label syntax is incorrect
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:1006)
at org.glassfish.webservices.WebServicesDeployer.downloadFile(WebServicesDeployer.java:419)
at org.glassfish.webservices.WebServicesDeployer.downloadWsdlsAndSchemas(WebServicesDeployer.java:290)
at org.glassfish.webservices.WebServicesDeployer.setupJaxWSServiceForDeployment(WebServicesDeployer.java:234)
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:167)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:922)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:431)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:235)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:257)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:745)
]]






[GLASSFISH-21167] Resource injection not working when empty <absoluteOrdering> is used in web.xml, for classes packed as jars in lib folder Created: 20/Aug/14  Updated: 08/Sep/14

Status: Open
Project: glassfish
Component/s: ejb_container, web_services
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: cristim1979 Assignee: Srini
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 7 64bit. Java: 7u67 (also 7u51, 8u11).
Glassfish: 4.0, 4.1-b12 (nightly build)



 Description   

Resource injection does not work, in EJBs of an application (in war format), when these 2 conditions are both met:

1) The application uses, in web.xml file, an empty <absoluteOrdering> tag
2) The code (classes) of the application are all packed as jar archives in the [war]\WEB-INF\lib\ folder, instead of included them unpacked in the [war]\WEB-INF\classes\ folder

(purpose for doing this:

  • 1: for disabling altogether the scanning for web-fragment.xml files in all of the included library jar files, as not necessary;
  • 2: for applications with a big codebase, which is structured in separate modules, easy to pack as separate jars)

When the 2 conditions are met, resource injection does not work.
This is visible for example in EJBs marked with @Singleton @Startup, which have fields marked with @EJB or @Resource:

  • the Singleton beans are identified and constructed by the container
  • then resource injection for fields is skipped ?
  • then the methods marked with @PostConstruct are identified and called, but they may result in NullPointerException if using the fields expected to be injected by now.

If any of the 2 conditions is changed (either remove <absoluteOrdering/> tag OR include the ejb classes unpacked, in the WEB-INF\classes folder), injection works as it should.

This works well on older Glassfish 3.1.2.2 version.
Fails on 4.0 version; also tested on latest promoted nightly build, 4.1-b12, and still fails.



 Comments   
Comment by cristim1979 [ 20/Aug/14 ]

Test example:

1) Have a simple application with just 2 Singleton EJBs:
TestSingleton1.java:

package com.spmsoftware.test;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import javax.ejb.EJB;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.ejb.TimerService;

@Singleton
@Startup
public class TestSingleton1 {
    @Resource
    public TimerService timerService;
    @EJB
    public TestSingleton2 testSingleton2;

    public TestSingleton1() {
        System.out.println("In TestSingleton1 constructor: injected fields state: @Resource timerService=" + timerService + "; @EJB testSingleton2=" + testSingleton2);
    }

    @PostConstruct
    public void init() {
        System.out.println("In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=" + timerService + "; @EJB testSingleton2=" + testSingleton2);
    }
}

TestSingleton2.java:

package com.spmsoftware.test;

import javax.annotation.PostConstruct;
import javax.ejb.Singleton;

@Singleton
public class TestSingleton2 {
    public TestSingleton2() {
        System.out.println("TestSingleton2 constructor called.");
    }

    @PostConstruct
    public void init() {
        System.out.println("TestSingleton2 @PostConstruct method called.");
    }
}

2) Define also a web.xml file for the app:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

    <!-- Just to ignore / not scan any web-fragment.xml files from jar files -->
    <absolute-ordering/>

</web-app>

3) Compile classes and pack the application as a war with this structure:

  • [test_app.war] (exploded, as folder)
    • in WEB-INF folder: the web.xml file
    • in WEB-INF\lib\ folder: a jar archive, test_app.jar, containing the compiled singleton classes

Testing:
Deploy the test application war on GF 4.0, and check console/log output related to the test singletons:

a) Incorrect output - when run on current GF 4.0 (note the null values on last line):

  EJB5181:Portable JNDI names for EJB TestSingleton1: [java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton1!com.spmsoftware.test.TestSingleton1, java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton1]
  In TestSingleton1 constructor: injected fields state: @Resource timerService=null; @EJB testSingleton2=null
  EJB5181:Portable JNDI names for EJB TestSingleton2: [java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton2!com.spmsoftware.test.TestSingleton2, java:global/test_app_war_ejb_classes_packed_in_jar/TestSingleton2]
  TestSingleton2 constructor called.
  In TestSingleton1 constructor: injected fields state: @Resource timerService=null; @EJB testSingleton2=null
  In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=null; @EJB testSingleton2=null

b) Correct output - when run on GF 3.1.2.2 (or on GF 4 with one of the 2 conditions changed) - similar, except for the last line:

  In TestSingleton1 @PostConstruct method: injected fields state: @Resource timerService=com.sun.ejb.containers.EJBTimerServiceWrapper@7ec0c910; @EJB testSingleton2=com.spmsoftware.test.TestSingleton2@22d07a73
Comment by cristim1979 [ 08/Sep/14 ]

Any update on this / any plans to handle it in 4.1 release ?





[GLASSFISH-21165] Adding MessageDumpingFeature sometimes causes the body of the message to disappear! Created: 14/Aug/14  Updated: 14/Aug/14

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: BasVandenBroek Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows, Unix. Various versions of JDK 1.6 and 1.7.



 Description   

When adding a MessageDumpingFeature when calling service.createDispatch, in some cases the body is removed from the soap request when the web service is called. This obviously does not happen in all cases but we've had various cases where it does occur. I have made a test project that reproduces this issue.

Note I'm trying to file this ticket here as well instead of just on METRO because I can't seem to add an attachment there.



 Comments   
Comment by BasVandenBroek [ 14/Aug/14 ]

Ok something is up with adding attachments, I can't do it here either. So please refer to the original ticket at https://java.net/jira/browse/METRO-30





[GLASSFISH-21114] Failure to lookup EJB in ear/war Created: 01/Jul/14  Updated: 14/Apr/16

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1_b05, 4.1_b06, 4.1_b07
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dbcjbn Assignee: Marek Potociar
Resolution: Unresolved Votes: 18
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-review, fishcat

 Description   

I have an ear which includes an EJB and a jax-rs WAR module, both listed in the application.xml file of the EAR.

The war contains jax-rs Application and resource bean classes, and the resource class injects stateless bean from the EJB module using @EJB annotation.

When I access the REST resource after deploy GlassFish is unable to locate the jax-rs resource bean, which lives inside the WAR. It looks like GlassFish assumes it is to be found in the EJB module (see Stacktrace below).

I have a small example application exhibiting this problem, that I will gladly upload if possible.

The problem does not appear to be in GlassFish versions 4.0 up to and including 4.0.1 b04.

We have done testing on both Java 7 and 8.

[2014-07-01T12:06:22.179+0200] [glassfish 4.0] [WARNING] [] [org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider] [tid: _ThreadID=123 _ThreadName=http-listener-1(1)] [timeMillis: 1404209182179] [levelValue: 900] [[
An instance of EJB class, dk.dbc.gf.ejb.HelloWorldBean, could not be looked up using simple form name. Attempting to look up using the fully-qualified form name.
javax.naming.NamingException: Lookup failed for 'java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NameNotFoundException: No object bound to name java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookupSimpleForm(EjbComponentProvider.java:378)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookup(EjbComponentProvider.java:360)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.access$000(EjbComponentProvider.java:100)
at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider$EjbFactory.provide(EjbComponentProvider.java:123)
at org.jvnet.hk2.internal.FactoryCreator.create(FactoryCreator.java:96)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2151)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:641)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:626)
at org.glassfish.jersey.internal.inject.Injections.getOrCreate(Injections.java:172)
at org.glassfish.jersey.server.model.MethodHandler$ClassBasedMethodHandler.getInstance(MethodHandler.java:185)
at org.glassfish.jersey.server.internal.routing.PushMethodHandlerRouter.apply(PushMethodHandlerRouter.java:74)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:112)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:115)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:94)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:63)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:261)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:252)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1025)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:382)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:345)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:220)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.naming.NameNotFoundException: No object bound to name java:app/gf-4.0.1-fail-ejb-1.0-SNAPSHOT/HelloWorldBean
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:741)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:167)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
... 64 more
]]



 Comments   
Comment by Joe Di Pol [ 01/Jul/14 ]

There have been some recent Jersey integrations. Assigning to Jakub for initial evaluation.

Comment by dbcjbn [ 04/Aug/14 ]

Would you happen to have an estimate on when this issue will be addressed, please?

Comment by dbcjbn [ 10/Sep/14 ]

This bug has also been observed on GlassFish v4.1

Comment by sgerr [ 16/Sep/14 ]

Bug is reproduced at Glassfish 4.1. It seems it is related to https://java.net/jira/browse/JERSEY-2122, but Jersey bug is at fixed state (fix version is 2.6), whereas Glassfish 4.1 is packaged with jersey of version 2.10.4-0. Unfortunately, this bug still appears. Is it scheduled for resolution?

Comment by giates2000 [ 21/Sep/14 ]

Due to this issue all my working jee7 rest web services are now stopped on glassfish v. 4.1, is there any workaround ?

Comment by gray [ 20/Oct/14 ]

I've found what is causing this bug and added comment to https://java.net/jira/browse/JERSEY-2122.

Comment by gray [ 21/Oct/14 ]

https://java.net/jira/browse/JERSEY-2690

Comment by MarvinEmilBrach [ 08/Mar/15 ]

posssible workaround: replace @Stateless with:
@javax.enterprise.context.RequestScoped
@javax.enterprise.context.ApplicationScoped
@javax.enterprise.context.ConversationScoped // NOT tested
@javax.enterprise.context.SessionScoped // NOT tested

perhaps related to https://java.net/jira/browse/GLASSFISH-21199

Comment by dobromyslov [ 15/Mar/15 ]

@RequestScoped breaks transactions in Jersey and it requires to mark methods as @Transactional.

Also Weld does not work well with @RequestScoped and raises an exception sometimes:
https://issues.jboss.org/browse/WELD-1774

Comment by dobromyslov [ 22/Mar/15 ]

java.lang.IllegalStateException: WELD-000335: Context is already active
Raises when I redeploy with JRebel.
It's been fixed in WELD 2.2.8.Final.

Comment by Sparksis [ 16/May/15 ]

I've submitted a pull request which fixes the issue in Jersey: https://github.com/jersey/jersey/pull/162

Unfortunately the the pull request is still pending.

Comment by nabizamani [ 14/Apr/16 ]

Is this here still an open issue? I'm just wondering because there is no reaction from Oracle!

Comment by Jakub Podlesak [ 14/Apr/16 ]

I am no longer on Jersey team. IIUC, this has already been fixed in Jersey (as per https://github.com/jersey/jersey/commit/8636f65b992322008bb987409af0dd97dec3b95f ). So this bug should get fixed in GlassFish once the corresponding Jersey version gets integrated.





[GLASSFISH-21106] Web Service Tester fails with NPE in GF 4.0.1 b6 Created: 25/Jun/14  Updated: 25/Jun/14

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.1_b06
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Kim Haase Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using the promoted b06 of GF 4.0.1 on Windows and running the JAX-WS example described in the Java EE 7 Tutorial at http://docs.oracle.com/javaee/7/tutorial/doc/jaxws001.htm#BNAYN, I get an NPE when running the tester. The same NPE occurs when running the tester from the Admin Console. The web service is deployed, the WSDL is visible, and the appclient and web client both work fine. Only the tester fails.

Here is the stack trace.

java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:459) at java.util.Properties.setProperty(Properties.java:166) at java.lang.System.setProperty(System.java:793) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.wsImport(WebServiceTesterServlet.java:619) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:526) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.doGet(WebServiceTesterServlet.java:173) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:104) at org.glassfish.webservices.JAXWSServlet.doGet(JAXWSServlet.java:210) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282) at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167) at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201) at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175) at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) at java.lang.Thread.run(Thread.java:744)






[GLASSFISH-21099] jaxws fail with a basic service Created: 24/Jun/14  Updated: 05/Aug/14  Resolved: 17/Jul/14

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0, 4.1_b07
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: David Delabassee Assignee: miroslav.kos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SE 1.7.0_51-b1 and SE 1.8.0_05-b13
OS X Mavericks


Tags: 4_0_1-mustfix

 Description   

Basic HelloWorld WS (see below) doesnt work.
Tested using the GF Web Admin WS Tester UI.

SE 1.7.0_51-b13 + GF 4.0 b89 : OK
SE 1.7.0_51-b13 + GF 4.0.1 b7 : FAIL - see below
SE 1.8.0_05-b13 + GF 4.0 b89 : FAIL - see below
SE 1.8.0_05-b13 + GF 4.0.1 b7 : FAIL - see below

--8<--
package delabassee;

import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.ejb.Stateless;

@WebService(serviceName = "MyWebService")
@Stateless()
public class NewWebService {

@WebMethod(operationName = "hello")
public String hello(@WebParam(name = "name") String txt)

{ return "Hello " + txt + " !"; }

}
--8<--

GF 4.0.1 / SE 7 :
java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:514) at java.util.Properties.setProperty(Properties.java:161) at java.lang.System.setProperty(System.java:787) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.wsImport(WebServiceTesterServlet.java:619) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:526) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.doGet(WebServiceTesterServlet.java:173) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:104) at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:143) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.glassfish.grizzly.servlet.ServletHandler.doServletService(ServletHandler.java:223) at org.glassfish.grizzly.servlet.ServletHandler.service(ServletHandler.java:174) at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167) at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201) at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175) at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) at java.lang.Thread.run(Thread.java:744)

GF 4.0.1 / SE 8 :
java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:459) at java.util.Properties.setProperty(Properties.java:166) at java.lang.System.setProperty(System.java:793) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.wsImport(WebServiceTesterServlet.java:619) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:526) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.doGet(WebServiceTesterServlet.java:173) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:104) at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:143) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.glassfish.grizzly.servlet.ServletHandler.doServletService(ServletHandler.java:223) at org.glassfish.grizzly.servlet.ServletHandler.service(ServletHandler.java:174) at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167) at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201) at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175) at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) at java.lang.Thread.run(Thread.java:745)

GF 4.0 / SE 8 :
"Internal Error" (no exception shown). From GF log :
[SEVERE] service exception: java.lang.AssertionError: org.xml.sax.SAXParseException; systemId: bundle://158.0:1/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd; lineNumber: 52; columnNumber: 88; schema_reference: Failed to read schema document 'xjc.xsd', because 'bundle' access is not allowed due to restriction set by the accessExternalSchema property. at com.sun.tools.xjc.SchemaCache.newValidator(SchemaCache.java:80) at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.apply(SCDBasedBindingSet.java:237) at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:541) at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:269) at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:95) at com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:142) at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2298) at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:198) at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:141) at com.sun.tools.ws.wscompile.WsimportTool.buildWsdlModel(WsimportTool.java:444) at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:205) at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:183) at com.sun.tools.ws.util.WSToolsObjectFactoryImpl.wsimport(WSToolsObjectFactoryImpl.java:60) at com.sun.tools.ws.spi.WSToolsObjectFactory.wsimport(WSToolsObjectFactory.java:88) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.wsImport(WebServiceTesterServlet.java:642) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:528) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.doGet(WebServiceTesterServlet.java:169) at org.glassfish.webservices.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:104) at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.glassfish.grizzly.servlet.ServletHandler.doServletService(ServletHandler.java:242) at org.glassfish.grizzly.servlet.ServletHandler.service(ServletHandler.java:193) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246) at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191) at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168) at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55) at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564) at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544) at java.lang.Thread.run(Thread.java:745) Caused by: org.xml.sax.SAXParseException; systemId: bundle://158.0:1/com/sun/tools/xjc/reader/xmlschema/bindinfo/binding.xsd; lineNumber: 52; columnNumber: 88; schema_reference: Failed to read schema document 'xjc.xsd', because 'bundle' access is not allowed due to restriction set by the accessExternalSchema property. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:441) at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4162) at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaFatalError(XSDHandler.java:4141) at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getSchemaDocument(XSDHandler.java:2168) at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.resolveSchema(XSDHandler.java:2078) at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:1008) at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:620) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:616) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:574) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:540) at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:255) at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:670) at com.sun.tools.xjc.SchemaCache.newValidator(SchemaCache.java:77) ... 39 more
[WARNING] schema_reference: Failed to read schema document 'NewWebService?xsd=1', because 'http' access is not allowed due to restriction set by the accessExternalSchema property.



 Comments   
Comment by miroslav.kos [ 02/Jul/14 ]

According stacktrace it seems the problem is new JAXP (1.5) which restricts access to external resources. There exist workarounds how to avoid this without any code change:

1) define JAXB-RI specific property to disable XML security (add JVM option to glassfish config):
-Dcom.sun.xml.bind.disableXmlSecurity=true

2) define standard JAXP propety to allow access:
-Djavax.xml.accessExternalSchema=file,bundle .... whatever you need ...
This can be defined by system property or via property file configured for JDK installation, see details here: https://jaxp.java.net/1.5/JAXP1.5Guide.html

The drawback of those solutions are that you releasing security restrictions for whole all JAXB-RI code (option 1) or for all JAXP processing being done within Glassfish installation or even JDK installation (option 2)

The other way is to release this restriction just for JAX-WS for this case, but it would require fixing it in upstream project and integration into Gv4.

Please let me know, what way you prefer to go.

Comment by miroslav.kos [ 03/Jul/14 ]

I finished testing of that - there are basically two different bugs:

1) already described problem with JAXP 1.5. I tested two different jvm options, both helped the Tester for simple WS succeeded:
asadmin create-jvm-options -Dcom.sun.xml.bind.disableXmlSecurity=true
asadmin create-jvm-options -Djavax.xml.accessExternalSchema=bundle

2) NPE (for GF 4.0.1):
There is a code, not necessary any more in
org/glassfish/webservices/monitoring/WebServiceTesterServlet.java:618
there are being found JAXB and JAXWS osgi bundles and there is java system property being set. The reason of NPE is that the bundles are not found (their names changed but are hardcoded in the WebServiceTesterServlet).
Anyway this property was set because of apt (at least comment says it) which is not used any more, so this failing code can be removed.

Comment by miroslav.kos [ 04/Jul/14 ]

Based on our discussion via email I am assigning this to you, let me know, if you have any additional questions

Comment by Joe Di Pol [ 07/Jul/14 ]

So two things need to be done:

1) The following JVM options need to be set by default on the domain:
asadmin create-jvm-options -Dcom.sun.xml.bind.disableXmlSecurity=true
asadmin create-jvm-options -Djavax.xml.accessExternalSchema=bundle

2) The NPE in WebServiceTesterServlet.java as described by Miroslav above needs to be fixed.

Assigning to Lukas to fix the NPE. I'll take care of the JVM options and update this bug when I've made the change.

Comment by Joe Di Pol [ 07/Jul/14 ]

FYI, setting -Djavax.xml.accessExternalSchema=bundle appears to break the GlassFish console, so we won't be setting that!

Comment by miroslav.kos [ 08/Jul/14 ]

Adding just the first jvm option is enough to fix the issue (com.sun.xml.bind.disableXmlSecurity)

Comment by miroslav.kos [ 09/Jul/14 ]

Please let me know, if the changing configuration is acceptable for you. Problem #2 fixed in code. Thanks

Comment by Joe Di Pol [ 09/Jul/14 ]

r63449: Added JVM option "-Dcom.sun.xml.bind.disableXmlSecurity=true" to domain.xml

Comment by Joe Di Pol [ 09/Jul/14 ]

Adding the JVM option caused a failure when security manager is on, so I had to revert r63449:

javax.xml.parsers.ParserConfigurationException: FEATURE_SECURE_PROCESSING: 
 Cannot set the feature to false when security manager is present.
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:122)
	at com.sun.xml.bind.v2.util.XmlFactory.createParserFactory(XmlFactory.java:128)
	at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getXMLReader(UnmarshallerImpl.java:154)
	at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:172)

So it looks like we may need a more sophisticated fix.

Comment by David Delabassee [ 16/Jul/14 ]

?! This (simple web service) now works ok on B8 (Jul15) with and without the security manager?!

Comment by miroslav.kos [ 17/Jul/14 ]

There were several commits for this issue, the last one fixing the issue is from 07/11:

r63469 | miroslav.kos | 2014-07-11 11:26:48 +0200 (Fri, 11 Jul 2014) | 1 line
GLASSFISH-21099: set javax.xml.accessExternalSchema=all

Recently also test added to QL:
r63483 | miroslav.kos | 2014-07-14 17:58:31 +0200 (Mon, 14 Jul 2014) | 1 line
GLASSFISH-21099: added test into QL tests





[GLASSFISH-21081] Why isn't my @InstanceResolverAnnotation being used on Web Service EJBs? Created: 05/Jun/14  Updated: 06/Jun/14  Resolved: 06/Jun/14

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b23
Fix Version/s: 4.1_b07

Type: Bug Priority: Major
Reporter: dankaplan Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File gf21081.patch    

 Description   

This comes from an email I sent on the mailing list titled "Why isn't my @InstanceResolverAnnotation being used in Glassfish 3.1.2?"

"You can find the source code I'm using here: https://java.net/projects/jax-ws-commons/sources/svn/show/trunk/guice/src/main/java/org/jvnet/jax_ws_commons/guicemanaged

Why doesn't the GuiceManagedInstanceResolver get used? I can easily hit breakpoints in the GuiceManagedFeature, but not the GuiceManagedInstanceResolver. Is com.sun.xml.ws.api.server.InstanceResolverAnnotation ignored now? What was it replaced with?"

I'm not able to hit a break point on org/glassfish/webservices/WSServletContextListener.java:273 which is this line:

        // See if it is configured with JAX-WS extension InstanceResolver annotation like
        // @com.sun.xml.ws.developer.servlet.HttpSessionScope or @com.sun.xml.ws.developer.Stateful
        InstanceResolver ir = InstanceResolver.createFromInstanceResolverAnnotation(serviceEndpointClass);  //line 273
        //TODO - Implement 109 StatefulInstanceResolver ??
        if (ir == null) {
            //use our own InstanceResolver that does not call @PostConstuct method before
            //@Resource injections have happened.
            ir = new InstanceResolverImpl(serviceEndpointClass);
        }
        Invoker inv = ir.createInvoker();

That's because this class doesn't seem to be used for EJB web services. Instead, I can hit a break point on this line org/glassfish/webservices/EjbRuntimeEndpointInfo.java:270

                        // Create the jaxws2.1 invoker and use this
                        Invoker invoker = new InstanceResolverImpl(clazz).createInvoker(); //line 270
                        WSEndpoint wsep = WSEndpoint.create(
                                clazz, // The endpoint class
                                false, // we do not want JAXWS to process @HandlerChain
                                new EjbInvokerImpl(clazz, invoker, webServiceEndpointServant, wsCtxt), // the invoker
                                endpoint.getServiceName(), // the service QName
                                endpoint.getWsdlPort(), // the port
                                container,
                                binding, // Derive binding
                                primaryWsdl, // primary WSDL
                                docs, // Collection of imported WSDLs and schema
                                catalogURL
                                );

So my understanding is that this should have an if statement just like the first code, otherwise InstanceResolverAnnotation get ignored. I may misunderstand, so I'll include Lukas Jungmann's words:

> Ah, my bad, should do the 'grep' earlier... Other place where InstanceResolver is being created is org/glassfish/webservices/EjbRuntimeEndpointInfo, around line 263 - maybe that's the place which is missing an 'if' condition, can you check that with a breakpoint and if that's the case, file a bug, please?

The reason I care about this is that I'd like to use Guice in my EJB web services for dependency injection, and this is getting in my way. See the source linked at the top to see how this is possible with InstanceResolverAnnotation as long as the web service is defined in a servlet. I'd like to be able to do the same thing in my web service defined in an EJB.



 Comments   
Comment by Lukas Jungmann [ 06/Jun/14 ]

patch for this issue

Comment by Lukas Jungmann [ 06/Jun/14 ]

https://java.net/projects/glassfish/sources/svn/revision/63343





[GLASSFISH-21038] domain.xml application context race condition Created: 11/Apr/14  Updated: 19/Nov/15

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jovok Assignee: Martin Grebac
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

Windows 7 OS



 Description   

My team is experiencing an issue with deploying a war file containing web services. When the war is generated and then deployed, the following line is sometimes missing from the domain.xml file under domains/domain1/config:

<engine sniffer="webservices"></engine>

Other facts:
-Attempting to access any web service then results in an error involving the javax.servlet.jar, for reasons unknown.
-Nothing in our project ever modifies the domain.xml file
-Using the /exact/ same war file, un-deploying and then re-deploying randomly results in the <engine sniffer="webservices"></engine> line being present or missing. The war file is not regenerated, we just have to undeploy and redeploy.
-Adding the <engine sniffer="webservices"></engine> manually to the domain.xml file, stopping the server, and restarting the server fixes the issue, and the inverse is also true.
-There are other <engine sniffer=".*"></engine> lines that are always present.



 Comments   
Comment by Hong Zhang [ 11/Apr/14 ]

Can you attach a reproducible test case for us to reproduce and look from our side?

Assign to web services team for initial evaluation.

Comment by Jovok [ 17/Apr/14 ]

I'm unable to produce a test case to submit, I can't pare down our code base enough to make it releasable. I'd be happy to take a look at it myself if I could get a copy of the glassfish4 source. If it helps, I'm almost certain its a threading issue, our code base is quite large, and it's seemingly random if a deploy will work or not.

Comment by sisirhc [ 24/Jun/14 ]

On our environment we experience the same behavior with Glassfish 3.1.2.2.

The operating system doesn't seem to influence, the issue occurs on Windows as well on Ubuntu an CentOS. The JDK in use is JDK 7 update 45. But also with the JDK we experience the issue with different version.

The deployment archive we are using is an EAR file using a number of sub projects which are web, ejb and webservices. One of the projects in a JAR package with beans annotated with "@java.jws.WebService". This package is not always correctly marked as web service package.

Here is a logging snapshot

[#|2014-06-24T17:15:10.449+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.annotation.impl.ModuleScanner;MethodName=calculateResults;|Adding my.company.AddMessagesWebServiceBean since my.company.AddMessagesWebServiceBean is annotated with javax.ejb.Stateless|#]
[#|2014-06-24T17:15:10.457+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.annotation.impl.ModuleScanner;MethodName=calculateResults;|Adding my.company.AddMessagesWebServiceBean since messageConnector is annotated with javax.ejb.EJB|#]
[#|2014-06-24T17:15:10.459+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.annotation.impl.ModuleScanner;MethodName=calculateResults;|Adding my.company.AddMessagesWebServiceBean since my.company.AddMessagesWebServiceBean is annotated with javax.jws.WebService|#]
[#|2014-06-24T17:15:10.459+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.annotation.impl.ModuleScanner;MethodName=calculateResults;|Adding my.company.AddMessagesWebServiceBean since sc is annotated with javax.annotation.Resource|#]
[#|2014-06-24T17:15:16.883+0200|FINER|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.node.SaxParserHandler;MethodName=endElement;|End of element  local name ejb-name and ejb-name value AddMessagesWebServiceBean|#]
[#|2014-06-24T17:15:16.883+0200|FINER|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.node.SaxParserHandler;MethodName=endElement;|For element ejb-name And value AddMessagesWebServiceBean|#]
[#|2014-06-24T17:15:16.884+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.node.DeploymentDescriptorNode;MethodName=setDescriptorInfo;|in class com.sun.enterprise.deployment.WebServiceEndpoint  method  setEndpointAddressUri with  /ht-tms-gmsg/GreenMessengerService/AddMessagesWebServiceBean|#]
[#|2014-06-24T17:15:16.884+0200|FINER|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.node.SaxParserHandler;MethodName=endElement;|End of element  local name endpoint-address-uri and endpoint-address-uri value /ht-tms-gmsg/GreenMessengerService/AddMessagesWebServiceBean|#]
[#|2014-06-24T17:15:16.884+0200|FINER|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.node.SaxParserHandler;MethodName=endElement;|End of element  local name port-component-name and port-component-name value AddMessagesWebServiceBean|#]
[#|2014-06-24T17:15:16.884+0200|FINER|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.node.SaxParserHandler;MethodName=endElement;|For element endpoint-address-uri And value /ht-tms-gmsg/GreenMessengerService/AddMessagesWebServiceBean|#]
[#|2014-06-24T17:15:16.884+0200|FINER|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.node.SaxParserHandler;MethodName=endElement;|For element port-component-name And value AddMessagesWebServiceBean|#]
[#|2014-06-24T17:15:16.996+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.util.EjbBundleValidator;MethodName=accept;|Visiting RefLocal ejb-ref name=my.company.AddMessagesWebServiceBean/messageConnector,Local 3.x interface =my.company.connector.MessageConnectorLocal,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session|#]
[#|2014-06-24T17:15:16.997+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.util.EjbBundleValidator;MethodName=accept;|Done Visiting AddMessagesWebServiceBean reference Local ejb-ref name=my.company.AddMessagesWebServiceBean/messageConnector,Local 3.x interface =my.company.connector.MessageConnectorLocal resolved to intra-app EJB MessageConnector in module ht-connector.jar,ejb-link=ht-connector.jar#MessageConnector,lookup=,mappedName=,jndi-name=,refType=Session|#]
[#|2014-06-24T17:15:17.433+0200|FINEST|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.appserv.connectors.internal.api.AppSpecificConnectorClassLoaderUtil;MethodName=detectResourceInRA;|could not find resource by name : my.company.AddMessagesWebServiceBean/sc|#]
[#|2014-06-24T17:15:18.205+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=81;_ThreadName=Thread-2;ClassName=com.sun.enterprise.deployment.Application;MethodName=setUniqueId;|Ejb  ht-tms-gmsg-2.7.0-SNAPSHOT.jar:AddMessagesWebServiceBean id = 91987831535894769|#]

Comparing the above log file to a unsuccessful deployment the only line that seems to be missing is

Adding my.company.AddMessagesWebServiceBean since my.company.AddMessagesWebServiceBean is annotated with javax.jws.WebService

The occurrence seems to be random but always related to deployments and not to restarts. It's possible to have multiple deployment successes but also to have multiple failures.

Adding the engine tag in the domain.xml seems to resolve the problem (until a new deploy is done).

Comment by mebemikeyc [ 19/Nov/15 ]

I experienced the same issue with one of my applications while migrating to GlassFish 4.1.1. This seems to be caused by class annotation introspection failing to find the annotations defined in org.glassfish.webservices.connector.WebServicesSniffer.

Looking into that file I discovered that, as a workaround, adding a WEB-INF/webservices.xml file will also trigger the engine to be added to the domain.xml.





[GLASSFISH-21037] Glassfish fails to inject javax.xml.ws.Service instance Created: 10/Apr/14  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: matthiasblaesing Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I try to inject a @WebServiceClient class into a singleton ejb. This fails. I have this:

@Singleton
@Startup
public class CacheManager {
    [...]
    @WebServiceRef(ZIGeneratorService.class)
    private ZIGenerator generator;
    [...]
}

This works as expected. Now I want to change that to inject the Service, not the port, so I change the above to:

@Singleton
@Startup
public class CacheManager {
    [...]
    @WebServiceRef(ZIGeneratorService.class)
    private ZIGeneratorService generator;
    [...]
}

According to the javadoc this should be possible:

http://docs.oracle.com/javaee/6/api/javax/xml/ws/WebServiceRef.html

The WebServiceRef annotation is used to define a reference to a web service and (optionally) an injection target for it. It can be used to inject both service and proxy instances.

But I get this:

Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Env-Prop: de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager/generator@Field-Injectable Resource. Class name = de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager Field name=generator@javax.jws.WebServiceRef@@@ into class de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager: Lookup failed for 'java:comp/env/de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager/generator' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:717)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:484)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:170)
	at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:138)
	... 50 more
Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/env/de.persona.dev.blaesing.test.simpleznwfrontend.CacheManager/generator' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException [Root exception is com.sun.xml.ws.model.RuntimeModelerException: Eine WebService-Annotation ist in Klasse nicht vorhanden: webservice.ZIGeneratorService]]
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
	at javax.naming.InitialContext.lookup(Unknown Source)
	at javax.naming.InitialContext.lookup(Unknown Source)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:613)
	... 53 more
Caused by: javax.naming.NamingException [Root exception is com.sun.xml.ws.model.RuntimeModelerException: Eine WebService-Annotation ist in Klasse nicht vorhanden: webservice.ZIGeneratorService]
	at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:271)
	at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:1082)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:745)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
	at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:159)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
	... 57 more
Caused by: com.sun.xml.ws.model.RuntimeModelerException: Eine WebService-Annotation ist in Klasse nicht vorhanden: webservice.ZIGeneratorService
	at com.sun.xml.ws.model.RuntimeModeler.getPortTypeName(RuntimeModeler.java:1621)
	at com.sun.xml.ws.model.RuntimeModeler.getPortTypeName(RuntimeModeler.java:1613)
	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:453)
	at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:474)
	at javax.xml.ws.Service.getPort(Service.java:203)
	at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:231)
	... 62 more
|#]

Sorry for the german translation, but the glassfish instance ignores the locale override I set via the console... [If needed I can translate]

For reference these are the skeletons for the classes:

@WebService(name = "ZIGenerator", targetNamespace = "http://znw.blaesing.dev.persona.de/")
@XmlSeeAlso({
    ObjectFactory.class
})
public interface ZIGenerator {
 [...]
}
@WebServiceClient(name = "ZIGeneratorService", targetNamespace = "http://znw.blaesing.dev.persona.de/", wsdlLocation = "/WEB-INF/wsdl/it-u1411_8080/SimpleZNWBackend/ZIGeneratorService.wsdl")
public class ZIGeneratorService extends Service {
}

The artifacts are genereted by jaxws maven. I need the service, because according to this:

http://stackoverflow.com/questions/6627482/webservice-client-service-instantiation

I can use the service from multiple threads, while the Port objects are not safe to use that way.



 Comments   
Comment by amy.yang [ 15/Apr/14 ]

I don't see any EJB issue here. It might need web service team to look after





[GLASSFISH-20883] @WebServiceRef fails to find WSDL location when path contains dots Created: 06/Nov/13  Updated: 06/Nov/13

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Xavi Arias Assignee: Martin Grebac
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP SP3, Glassfish Embedded 3.1.2.2


Tags: glassfish-3-1-2-2, jax-ws, webservices

 Description   

When annotating a @WebServiceRef that points to a relative WSDL location, the resolver for this location wrongly parses the absolute path of the file.

For example, when annotating a class field as:

{{@WebServiceRef(wsdlLocation = "file:/META-INF/wsdl/MyService.wsdl")
private MyService myService;}}

The resolved absolute path is:

file:/P:/TEMP/gfembed289186035449683125tmp/applications/my_app_ear-1.1.0-SNAPSHOT/my_web_module-1_1_0-SNAPSHOT_war/WEB-INF/wsdl/MyService.wsdl

The resolver changes all dots to underscores, instead of only changing the dot before the file extension. This obviously generates a FileNotFoundException.

So the correct path would be:

file:/P:/TEMP/gfembed289186035449683125tmp/applications/my_app_ear-1.1.0-SNAPSHOT/my_web_module-1.1.0-SNAPSHOT_war/WEB-INF/wsdl/MyService.wsdl

Strangely, the first part of the path containing the EAR directory is correct, it only fails in the resolution of the WAR directory.






[GLASSFISH-20832] Removing Metro Results in Exceptions on First Server Load Created: 30/Sep/13  Updated: 30/Sep/13

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mikevoxcap Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Enterprise, SP1. 64-bit.


Tags: admin-gui, metro

 Description   

1) Installed a new copy of 3.1.2.2 of Glassfish under my C drive.
2) Ran the updatetool to remove the component Metro Web Services Stack 2.2-13.1. This also removed glassfish-full-profile.
3) Attempted to start the server. The server start fails with the exception below. Attempted to start the server again and this time it starts.

EXECUTION TRACE

c:\glassfish-3.1\bin>asadmin start-domain --user admin das-local
Waiting for das-local to start ...Error starting domain das-local.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:

Launching GlassFish on Felix platform
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 275 installed from /C:/glassfish-3.1/glassfish/modules/jaxrpc-api-osgi.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 274 installed from /C:/glassfish-3.1/glassfish/modules/jaxr-api-osgi.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 278 installed from /C:/glassfish-3.1/glassfish/modules/soap-tcp.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 270 installed from /C:/glassfish-3.1/glassfish/modules/endorsed/jaxb-api-osgi.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 282 installed from /C:/glassfish-3.1/glassfish/modules/webservices-osgi.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 281 installed from /C:/glassfish-3.1/glassfish/modules/webservices-extra-jdk-packages.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 284 installed from /C:/glassfish-3.1/glassfish/modules/woodstox-core-asl.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 279 installed from /C:/glassfish-3.1/glassfish/modules/stax2-api.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 277 installed from /C:/glassfish-3.1/glassfish/modules/metro-glue.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 276 installed from /C:/glassfish-3.1/glassfish/modules/jsr109-impl.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 273 installed from /C:/glassfish-3.1/glassfish/modules/jaxb-osgi.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 272 installed from /C:/glassfish-3.1/glassfish/modules/ant.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 280 installed from /C:/glassfish-3.1/glassfish/modules/webservices-connector.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 283 installed from /C:/glassfish-3.1/glassfish/modules/webservices.security.jar
Sep 30, 2013 3:04:15 PM BundleProvisioner uninstall
INFO: Uninstalled bundle 271 installed from /C:/glassfish-3.1/glassfish/modules/endorsed/webservices-api-osgi.jar
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.glassfish.embeddable.GlassFishException: java.lang.IllegalStateException: Invalid Bund
leContext.
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFis
hRuntimeBuilder.java:164)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:11
2)
... 6 more
Caused by: java.lang.IllegalStateException: Invalid BundleContext.
at org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
at org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:173)
at com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.getBundle(BundleProvisioner.
java:397)
at com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.startBundles(BundleProvision
er.java:221)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFis
hRuntimeBuilder.java:153)
... 9 more
Error stopping framework: java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:203
)

Command start-domain failed.

c:\glassfish-3.1\bin>c:\startGlassfish.bat

c:\glassfish-3.1\bin>c:

c:\glassfish-3.1\bin>cd c:\glassf
ish-3.1\bin

c:\glassfish-3.1\bin>asadmin start-domain --user admin das-local
Waiting for das-local to start .......................
Successfully started the domain : das-local
domain Location: C:\glassfish-3.1\glassfish\domains\das-local
Log File: C:\glassfish-3.1\glassfish\domains\das-local\logs\server.
log
Admin Port: 4848
Command start-domain executed successfully.

If applications are installed, the removal of Metro results in null pointer exception thrown when listing applications through the Admin GUI:

[#|2013-09-30T15:17:18.937-0500|SEVERE|glassfish3.1.2|org.glassfish.admingui|_ThreadID=31;_ThreadName=Thread-2;|RestResponse.getResponse() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/applications/application/list-components.json'; attrs = '

{target=domain}'|#]

[#|2013-09-30T15:17:19.957-0500|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin|_ThreadID=32;_ThreadName=Thread-2;|Exception in command execution : java.lang.NullPointerException
java.lang.NullPointerException
at org.glassfish.deployment.admin.ListComponentsCommand.displaySnifferEngine(ListComponentsCommand.java:300)
at org.glassfish.deployment.admin.ListComponentsCommand.getSniffers(ListComponentsCommand.java:254)
at org.glassfish.deployment.admin.ListComponentsCommand.getAppSnifferEngines(ListComponentsCommand.java:236)
at org.glassfish.deployment.admin.ListComponentsCommand.execute(ListComponentsCommand.java:135)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1066)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
at org.glassfish.admin.rest.resources.TemplateExecCommand.executeCommand(TemplateExecCommand.java:127)
at org.glassfish.admin.rest.resources.TemplateCommandGetResource.processGet(TemplateCommandGetResource.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:148)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
|#]

[#|2013-09-30T15:17:19.961-0500|SEVERE|glassfish3.1.2|org.glassfish.admingui|_ThreadID=28;_ThreadName=Thread-2;|RestResponse.getResponse() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/applications/application/list-components.json'; attrs = '{target=domain}

'|#]






[GLASSFISH-20828] HttpSessionBindingListener.valueUnbound() is always called right after valueBound() with a null HttpSessionBindingEvent.getValue() Created: 27/Sep/13  Updated: 19/Sep/14  Resolved: 18/Apr/14

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: V3, 3.1.1, 3.1.2, 3.1.2.2
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: pbors Assignee: Lukas Jungmann
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Expected Behavior

Client code that register itself as a HttpSessionBindingListener insider GlassFish v3.1.2.2 and v4 should not be signaled via valueUnbound() unless the object is really being unbound from a session.

Actual Outcome

Whenever I register a HttpSessionBindingListener insider GlassFish v3.1.2.2 and v4 the valueUnbound() method is called with HttpSessionBindingEvent.getValue() null immediately after valueBound() when I register an object.

Steps to Reproduce

  1. Create your own filter and implementation of HttpSessionBindingListener
  2. Register an object and notice the sequence of callback as valueBound() with a valid HttpSessionBindingEvent.getValue() fallowed by valueUnbound() with a null HttpSessionBindingEvent.getValue()

Conform the JavaDoc on HttpSessionBindingListener the valueUnbound() method:

Notifies the object that it is being unbound from a session and identifies the session.

Thus it would be wrong to have it called immediately after valueBound().



 Comments   
Comment by pbors [ 27/Sep/13 ]

Related to GLASSFISH-4373

Comment by pbors [ 27/Sep/13 ]

Not a GlassFish bug, sorry for the wrong heads up.

For more details see this mailing list post.

Comment by Lukas Jungmann [ 18/Apr/14 ]

per last comment





[GLASSFISH-20740] @WebServiceRef annotation (at least its "value" member) does not work correctly on servlets and filters Created: 05/Aug/13  Updated: 11/Sep/15  Resolved: 11/Sep/15

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: bafco Assignee: Vinay Vishal
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_17"
Fedora 17


Issue Links:
Duplicate
duplicates GLASSFISH-21381 war with web service not deploying co... Resolved
Tags: javaee_ri_fix

 Description   

I try to inject a web service using @WebServiceRef(value = ...). When used on a member of a filter class (or a servlet class), I get "java.io.FileNotFoundException: http://bafco:8080/example-1.0/translator/__container$publishing$subctx/null?WSDL". However, this annotation works fine for managed and session beans (e.g. in Weld). Therefore, I suppose there is no mistake in configuration, etc. (Other Java EE component environment injection annotations (@EJB, @PersistenceUnit, ...) work fine even for filter/servlet classes.)

I hope I will be able to upload a simple example demonstrating this error + server.log with the complete stacktrace after the issue is created.
You should get the same result after deploying the example-1.0.war on GF 4.

For now, some code snippets:

public class TestFilter2 implements Filter {
    @WebServiceRef(value = TranslatorEndpointService.class)
    Translator translatorField;
    //...
}

public class TestServlet2 extends HttpServlet {
    @WebServiceRef(value = TranslatorEndpointService.class)
    Translator translatorField;
    //...
}

@WebServiceClient(name = "Translator", targetNamespace = "http://example.wsr.com/")
public class TranslatorEndpointService extends Service {
    public TranslatorEndpointService(URL wsdlDocumentLocation, QName serviceName) {
        super(wsdlDocumentLocation, serviceName);
    }
    
    @WebEndpoint(name="TranslatorPort")
    public Translator getTranslatorPort() {
        return super.getPort(Translator.class);
    }
}

@WebService(endpointInterface = "com.wsr.example.Translator", serviceName = "Translator")
public class TranslatorEndpoint implements Translator {
    public String translate(String sentence) {
        return "ok";
    }
}

@WebService(name = "TranslatorPortType", targetNamespace = "http://example.wsr.com/")
public interface Translator {
    @WebMethod
    public String translate(@WebParam String sentence);
}

part of web.xml:
...
<servlet>
<servlet-name>Translator</servlet-name>
<servlet-class>com.wsr.example.TranslatorEndpoint</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
<servlet>
<servlet-name>TestServlet2</servlet-name>
<servlet-class>com.wsr.example.TestServlet2</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>
<filter>
<filter-name>TestFilter2</filter-name>
<filter-class>com.wsr.example.TestFilter2</filter-class>
</filter>
...



 Comments   
Comment by bafco [ 05/Aug/13 ]

As uploading files is disabled and editing description too (at least for me), I created a git repository with example source code here: https://github.com/bafco/GF_ISSUES/tree/GLASSFISH-20740. It contains a maven project, copy-pasted server.log and a deployable .war archive.

Comment by Vinay Vishal [ 11/Sep/15 ]

This issue is exactly the same as 21381. 21381 has been resolved.

Comment by Vinay Vishal [ 11/Sep/15 ]

Linked duplicate issue 21381 has been resolved.





[GLASSFISH-20661] web service endpoint is not available for the deployed EJB application Created: 25/Jun/13  Updated: 22/Jul/15

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: xianwu Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)



 Description   

Reproducible operational steps:
asadmin deploy ws_ejb_ng.jar
Application deployed with name ws_ejb_ng.
Command deploy executed successfully.

Detailed description of the issue:
The deployed EJB application program has the settings below.

1) The WebService annotation and the EJB annotation are included at the same time.
@WebService annotation:
@javax.ws.WebService
@EJB annotation:
@javax.ejb.Stateless
2) The value of < ejb-name > in ejb-jar.xml is different from the value of @Stateless.

The deploy command is successful and no error messages are shown in server.log.
However the web service endpoint is not available.

The testing was under GlassFish v4 b89

If the value of < ejb-name > in ejb-jar.xml matches with the value of @Stateless (see ws_ejb_ok.jar),
then, the web service endpoint is available.

I will include sample applications and loggings late



 Comments   
Comment by xianwu [ 25/Jun/13 ]

Hi Chris

I have uploaded the sample applications and logging files at
https://github.com/xianwum/GLASSFISH-20661

List of Files
ws_ejb_ng.jar (EJB Application whose web service endpoint is not available)
ws_ejb_ng.log (server.log when the ws_ejb_ng.jar is deployed)
ws_ejb_ok.jar (EJB Application whose web service endpoint is available)
ws_ejb_ok.log (server.log when the ws_ejb_ok.jar is deployed)

The only difference between ws_ejb_ng.jar and ws_ejb_ok.jar is <ejb-name> in META-INF\ejb-jar.xml.

In ws_ejb_ok.jar#META-INF\ejb-jar.xml, we have "<ejb-name>HelloEJBa</ejb-name>"
but in ws_ejb_ng.jar#META-INF\ejb-jar.xml, we have "<ejb-name>HelloEJBb</ejb-name>"

In HelloEJB.java, we have

@WebService(endpointInterface="endpoint.Hello")
@Stateless(name = "HelloEJBa")
public class HelloEJB implements Hello {

public String sayHello(String who)

{ return "WebSvcTest-Hello " + who; }

}

Regards, Xianwu

Comment by marina vatkina [ 25/Jun/13 ]

Let's start with web-services

Comment by gregn123 [ 22/Jul/15 ]

This problem still exists in Glassfish 4.1.

I have fully explained the bug and it's cause, provided sample apps that illustrate and reproduce the bug, and provided a proposed patch for Glassfish 4.1 (source patch + corresponding binary) here:

https://github.com/gregn123/GLASSFISH-20661

Please see the README.txt file in the above GitHub repository for more details.





[GLASSFISH-20507] NullPointerException in RuntimeModelBuilder.java line 195 Created: 10/May/13  Updated: 11/Jan/16  Resolved: 11/Jan/16

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Critical
Reporter: mkarg Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.2.2, Win 7 Pro SP 1 (32 Bit), JDK 1.7.0_21


Attachments: GZip Archive GF_20507.tar.gz    
Tags: 4_0_1-approved, incomplete

 Description   

Application is working well on GlassFish 3.1.1, but not on 3.1.2.2!

When deploying on GlassFish 3.1.2.2 instead (with same environmental conditions), it crashes when JAXB-unmarshalling the exact same data! Since it works in GF 3.1.1, it seems GF 3.1.2.2 replaces working parts of JAXB by failing replacements!

Simplified stack trace:

com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder$IDTransducerImpl.parse() (line 195) <--- throws NPE here
com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.parse() (line 247)
...
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal() (line 219)
de.quipsy.util.http.HttpClient (line ...) <--- catched in my code when doing marshaller.unmarshal(InputStream).

Strange but true, this happens only with some XML content, but not with any other. And no, the InputStream is not null.

We cannot migrate from 3.1.1 to 3.1.2.2 because of this issue!



 Comments   
Comment by Martin Grebac [ 13/May/13 ]

Hi, thanks for submission. We can't do anything about it without the (as minimal as possible) reproducible testcase. Have you tried running your application against latest JAXB to verify if the issue is already fixed?

Comment by mkarg [ 13/May/13 ]

The problem is that the fault only happens in the middle of our full-size Enterprise application, which is a rather heavy sized EAR that Needs lots of resources and database tables to get to that Point that is crashing, unfortunately. I do not see any chance to provide a test case. So you need to tell me things I can trace to help you (like enabling Special logging levels). JAXB is the one contained in JRE 7u21. Is that what you mean with "latest" or how to make GlassFish use "latest"?

Comment by mkarg [ 02/Apr/14 ]

Bug still exists in GF 4.0 running on JDK 1.8.0!

This is a showstopper for us to migrate from 3.1.1 to 4.0 or at least 3.1.2.2.

Comment by mkarg [ 02/Apr/14 ]

Unfortunately I cannot test against 4.0.1-nightly-latest due to https://java.net/jira/browse/GLASSFISH-21027. As soon as GLASSFISH-21027 is fixed I will try whether the bug is possibly gone in 4.0.1 (in 4.0.0 it is still existing).

Comment by mkarg [ 03/Apr/14 ]

I found out that the problem can be reproduced in my EAR by the following:

  • Use @XmlID on a public String member of @XmlRootElement class Parent.
  • Use @XmlRefID on @XmlAttribute private Parent myParent within class Child.
  • Child itself is parent to another child, having @XmlID on its own so the Grand Child uses @XmlRefID again, etc.
    -> You get a chain of @XmlID parent – @XmlIDRef child – @XmlIDRef grandchild.

When unmarshalling such a JAXB tree in some cases (more often than not in my application) the failure occurs.

I can proof this by simple removing the @XmlID / @XmlIDRef annoations, which makes the unmarshalling work correctly, but certainly leading to wrong results (included copies of the parents instead of referenced singletons).

We really are stuck with this! It is a total showstopper! Please help us with a fix! If there is anything we can do to speed this up, please tell us right now!

Comment by mkarg [ 03/Apr/14 ]

Test project (WAR file incl. source code and Maven build script demonstrating the bug) sent directory to Iaroslav Savytskyi. The bug only happens with a class uses both, @XmlID and @XmlJavaTypeAdapter.

Comment by mkarg [ 10/Apr/14 ]

Provided WAR file with test code a week ago but did not even get any ack of receipt so far. Possibly you didn't get my emails or your answers are getting lost. Can you please ack here so I know that you received the test code?

Comment by Iaroslav Savytskyi [ 10/Apr/14 ]

User's test case.

Comment by Iaroslav Savytskyi [ 10/Apr/14 ]

Hi,

To be honest I can't promise any terms when we'll be able to start working on this.

Comment by mkarg [ 12/Apr/14 ]

Can you please provide us with a time frame when Oracle might be able to fix this critical bug? I mean, it is OK if this is not solved in the next weeks certainly, but we should have a GlassFish including a fixed JAXB within the next six months if any possible. In the end we talk about a showstopper without any existing workaround.

Comment by mkarg [ 19/May/14 ]

It's been six weeks since last contact so I'd like to kindly ask if meanwhile the planning is done, hence, whether at least Oracle could commit to fix this before GF 4.0.2 GA?

Comment by mkarg [ 20/Jun/14 ]

Another eight weeks later and not even a "ping" echo from Oracle on this crash issue. I wonder what's going on? Given up bug fixing on JAXB or possible the JAXB team sent to holidays in the caribbean sea? :-D

Comment by kdevaras [ 22/Jun/14 ]

The bug has been assigned to me(internally) and I'll be picking up this issue from this week.

Thanks.

Comment by mkarg [ 22/Jun/14 ]

That sounds very promising. I am looking forward to the final solution!

Comment by mkarg [ 05/Aug/14 ]

kdevaras, I really don't want to bother, but I would be totally happy if you could post a status update; thanks!

Comment by kdevaras [ 06/Aug/14 ]

I forgot to update it here.

There are actually a couple of updates.

The NPE is here:
UnmarshallingContext.getInstance().addToIdTable(value);

UnmarshallingContext.getInstance() is null.

An UnmarshallingContext instance is pushed to and popped from a ThreadLocal when entering a method and exiting a method respectively.

While debugging, it appeared that a pop was called out of turn. Hence the getInstance() call returned null.

This issue may be fixed in jaxb 2.2.8/2.2.9 as the Threadlocal strategy was reworked for an NPE. I'm trying to verify with that version.

Thanks.

Comment by kdevaras [ 06/Aug/14 ]

Btw, Glassfish seems to be using 2.2.5-5.

Comment by mkarg [ 06/Aug/14 ]

Thanks for the status update.

As GF-4.0.1 is soon to come, can you please inform GF team that 4.0.1 must not be published before your fix is merged into GF? I think it is really essential for GF as JAXB is a core technology. Without a recent status update they may think there will be no fix in time and publish without pulling latest JAXB. Thanks.

Comment by kdevaras [ 06/Aug/14 ]

Not sure if I can ask that.

Even if the fix is merged after the release, I'll try to provide a patch that can applied.

Thanks.

Comment by mkarg [ 09/Sep/14 ]

kdevaras, I'm currently reviewing the list of issues I reported against GF4 and kindly like to ask for a status update on the following of your above comments: "This issue may be fixed in jaxb 2.2.8/2.2.9 as the Threadlocal strategy was reworked for an NPE. I'm trying to verify with that version.". Did you find the time for this test and hence can you confirm that the problem is gone in JAXB 2.2.9? Also I wonder what the correct way is to ask the GlassFish team to incorporate at least 2.2.9 in GF 4.0.1 / 4.1 (whom to ask for that)?

Comment by kdevaras [ 28/Oct/14 ]

I got caught up with urgent issues. I'm now back to this one.

Strangely, I don't seem to be able to reproduce this issue anymore.
I'm using the same steps you described in go.cmd. I've checked on both 3.1.2.7 and 3.1.2.8.

Comment by mkarg [ 11/Jan/16 ]

Cannot reproduce issue using GlassFish 4.1.1. As I opened this ticket originally, I would recommend to close it now.





[GLASSFISH-20460] WSTCP0007:Transport module was not initialized! Created: 03/May/13  Updated: 19/Sep/14  Resolved: 06/May/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Sreekanth Assignee: Martin Grebac
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8, Cyginw, JDK 7 update 21



 Description   

In JAX-RM Functional, around 58 tests were failing due to this problem. This looks similar to the issue https://java.net/jira/browse/WSIT-1529. I am assuming the the fix for wsit-1529 is not ported to the Metro trunk.

[2013-05-02T20:47:48.090-0700] [glassfish 4.0] [SEVERE] [] [com.sun.metro.transport.tcp.server] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868090] [levelValue: 1000] [[
WSTCP0007:Transport module was not initialized!
java.lang.IllegalStateException: WSTCP0007:Transport module was not initialized!
at com.sun.xml.ws.transport.tcp.server.WSTCPModule.getInstance(WSTCPModule.java:71)
at com.sun.xml.ws.transport.tcp.server.glassfish.WSStartupServlet.contextInitialized(WSStartupServlet.java:105)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-05-02T20:47:48.092-0700] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00174] [javax.enterprise.web.core] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868092] [levelValue: 1000] [[
Startup of context /securesoaprtcponeway failed due to previous errors]]

[2013-05-02T20:47:48.093-0700] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00175] [javax.enterprise.web.core] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868093] [levelValue: 1000] [[
Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:934)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6099)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5916)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-05-02T20:47:48.094-0700] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00108] [javax.enterprise.web.core] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868094] [levelValue: 1000] [[
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.IllegalStateException: listener.parsingFailed
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5920)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IllegalStateException: listener.parsingFailed
at com.sun.xml.ws.transport.tcp.server.glassfish.WSStartupServlet.contextInitialized(WSStartupServlet.java:116)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
... 65 more
Caused by: java.lang.IllegalStateException: WSTCP0007:Transport module was not initialized!
at com.sun.xml.ws.transport.tcp.server.WSTCPModule.getInstance(WSTCPModule.java:71)
at com.sun.xml.ws.transport.tcp.server.glassfish.WSStartupServlet.contextInitialized(WSStartupServlet.java:105)
... 68 more
]]

[2013-05-02T20:47:48.095-0700] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868095] [levelValue: 900] [[
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalStateException: listener.parsingFailed
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalStateException: listener.parsingFailed
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1044)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2278)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-05-02T20:47:48.096-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868096] [levelValue: 1000] [[
Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalStateException: listener.parsingFailed
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-05-02T20:47:48.097-0700] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868097] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalStateException: listener.parsingFailed
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-05-02T20:47:48.097-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868097] [levelValue: 1000] [[
Exception while loading the app]]

[2013-05-02T20:47:48.098-0700] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=37 _ThreadName=admin-listener(5)] [timeMillis: 1367552868098] [levelValue: 1000] [[
Undeployment failed for context /securesoaprtcponeway]]



 Comments   
Comment by Martin Grebac [ 06/May/13 ]

Based on the test results, RM works fine, but issue is in SOAP/TCP on Windows. We certainly have to release note this.

Comment by Martin Grebac [ 06/May/13 ]

Test config issue - so closing based on email conv. with Sreekanth.





[GLASSFISH-20459] Error in Verifying Security in the Inbound Message. com.sun.xml.wss.impl.PolicyViolationException: ERROR: No security header found in the message Created: 03/May/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b86_RC2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sreekanth Assignee: Sreekanth
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows8, Cygwin, JDK7 update 21



 Description   

Few tests in wssecurity are failing with this exception. This bug might be a duplicate of issue : https://java.net/jira/browse/GLASSFISH-20458. But not sure. Hence filing this issue.

<?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope"><faultcode xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">wsse:FailedAuthentication</faultcode><faultstring>Authentication of Username Password Token Failed</faultstring></S:Fault></S:Body></S:Envelope>--------------------

May 02, 2013 8:29:52 PM com.sun.xml.wss.jaxws.impl.SecurityClientTube processClientResponsePacket
SEVERE: WSSTUBE0025: Error in Verifying Security in the Inbound Message.
com.sun.xml.wss.impl.PolicyViolationException: ERROR: No security header found in the message
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:138)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.createMessage(SecurityRecipient.java:1016)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:252)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.verifyInboundMessage(SecurityTubeBase.java:455)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientResponsePacket(SecurityClientTube.java:434)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:362)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1147)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
at com.sun.xml.ws.client.Stub.process(Stub.java:464)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:174)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:91)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:154)
at com.sun.proxy.$Proxy40.ping(Unknown Source)
at simple.client.PingServiceClients114.main(Unknown Source)

javax.xml.ws.WebServiceException: WSSTUBE0025: Error in Verifying Security in the Inbound Message.
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientResponsePacket(SecurityClientTube.java:439)Error : Exception on client side

at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:362)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1147)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
at com.sun.xml.ws.client.Stub.process(Stub.java:464)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:174)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:91)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:154)
at com.sun.proxy.$Proxy40.ping(Unknown Source)
at simple.client.PingServiceClients114.main(Unknown Source)
Caused by: javax.xml.ws.soap.SOAPFaultException: Invalid Security Header
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.getSOAPFaultException(SecurityTubeBase.java:715)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.getSOAPFaultException(SecurityTubeBase.java:733)
... 13 more
Caused by: com.sun.xml.wss.impl.WssSoapFaultException: Invalid Security Header
at com.sun.xml.wss.impl.SecurableSoapMessage.newSOAPFaultException(SecurableSoapMessage.java:349)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.getSOAPFaultException(SecurityTubeBase.java:729)
... 13 more



 Comments   
Comment by Sreekanth [ 03/May/13 ]

Fixed. Test framwework issue for windows 8





[GLASSFISH-20458] Error in Verifying Security in the Inbound Message. com.sun.xml.wss.impl.WssSoapFaultException: Authentication of Username Password Token Failed Created: 03/May/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b86_RC2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sreekanth Assignee: Sreekanth
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows8, Cygwin, JDK 7 update 21



 Description   

Hi,

Few tests in WsSecurity are failing with this problem.

2013-05-02T20:41:10.179-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.resource.xml.webservices.security] [tid: _ThreadID=23 _ThreadName=http-listener-1(5)] [timeMillis: 1367552470179] [levelValue: 1000] [[
WSS0221: Unable to locate matching certificate for 127901500862700997089151460209364726264:CN=OASIS Interop Test CA,O=OASIS using CallbackHandler.]]

[2013-05-02T20:41:10.182-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core.security.com.sun.enterprise.security.auth.login] [tid: _ThreadID=23 _ThreadName=http-listener-1(5)] [timeMillis: 1367552470182] [levelValue: 800] [[
SEC5046: Audit: Authentication refused for [wsitUser].]]

[2013-05-02T20:41:10.183-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core.security.com.sun.enterprise.security.jmac.callback] [tid: _ThreadID=23 _ThreadName=http-listener-1(5)] [timeMillis: 1367552470183] [levelValue: 800] [[
jmac.loginfail]]

[2013-05-02T20:41:10.183-0700] [glassfish 4.0] [SEVERE] [] [com.sun.xml.wss.logging.impl.filter] [tid: _ThreadID=23 _ThreadName=http-listener-1(5)] [timeMillis: 1367552470183] [levelValue: 1000] [[
WSS1408: UsernameToken Authentication Failed]]

[2013-05-02T20:41:10.183-0700] [glassfish 4.0] [SEVERE] [] [com.sun.xml.wss.jaxws.impl] [tid: _ThreadID=23 _ThreadName=http-listener-1(5)] [timeMillis: 1367552470183] [levelValue: 1000] [[
WSSTUBE0025: Error in Verifying Security in the Inbound Message.
com.sun.xml.wss.impl.WssSoapFaultException: Authentication of Username Password Token Failed
at com.sun.xml.ws.security.opt.impl.util.SOAPUtil.newSOAPFaultException(SOAPUtil.java:175)
at com.sun.xml.ws.security.opt.impl.incoming.UsernameTokenHeader.validate(UsernameTokenHeader.java:164)
at com.sun.xml.ws.security.opt.impl.incoming.processor.SecurityHeaderProcessor.createHeader(SecurityHeaderProcessor.java:192)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleEncryptedData(SecurityRecipient.java:658)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:470)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:296)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:245)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.verifyInboundMessage(SecurityTubeBase.java:455)
at com.sun.xml.wss.jaxws.impl.SecurityServerTube.processRequest(SecurityServerTube.java:295)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:420)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:687)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:266)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.invokeAsync(ServletAdapter.java:225)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:161)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:197)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:81)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
]]



 Comments   
Comment by Sreekanth [ 03/May/13 ]

Fixed. test Framework issue for windows 8. Committed to test workspace





[GLASSFISH-20457] SEVERE: WSS1518: Failed to validate certificate.java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors Created: 03/May/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b86_RC2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sreekanth Assignee: Sreekanth
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8, JDK 7 update 21



 Description   

Hi ,

4 tests in wssecurity policy are failing due to this reason. These tests are passing fine in Linux environment. This looks to me like config issue . But I am not sure. So filing the issue as I am trying to debug.

The soap log says:

May 03, 2013 5:27:36 AM com.sun.xml.wss.impl.misc.DefaultCallbackHandler$X509CertificateValidatorImpl validate
SEVERE: WSS1518: Failed to validate certificate
java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:208)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:279)
at com.sun.xml.wss.impl.misc.DefaultCallbackHandler$X509CertificateValidatorImpl.validate(DefaultCallbackHandler.java:1712)
at com.sun.xml.wss.impl.callback.CertificateValidationCallback.getResult(CertificateValidationCallback.java:87)
at com.sun.xml.wss.impl.misc.DefaultSecurityEnvironmentImpl.validateCertificate(DefaultSecurityEnvironmentImpl.java:813)
at com.sun.xml.ws.security.opt.impl.incoming.X509BinarySecurityToken.validate(X509BinarySecurityToken.java:185)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:423)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:296)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:245)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.verifyInboundMessage(SecurityTubeBase.java:455)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientResponsePacket(SecurityClientTube.java:434)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:362)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1147)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
at com.sun.xml.ws.client.Stub.process(Stub.java:464)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:174)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:91)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:154)
at com.sun.proxy.$Proxy38.ping(Unknown Source)
at simple.client.PingServiceClientu17.main(Unknown Source)

Error in sending request
javax.xml.ws.WebServiceException: com.sun.xml.wss.impl.WssSoapFaultException: Path does not chain with any of the trust anchors
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:365)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1147)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
at com.sun.xml.ws.client.Stub.process(Stub.java:464)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:174)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:91)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:154)
at com.sun.proxy.$Proxy38.ping(Unknown Source)
at simple.client.PingServiceClientu17.main(Unknown Source)
Caused by: com.sun.xml.wss.impl.WssSoapFaultException: Path does not chain with any of the trust anchors
at com.sun.xml.ws.security.opt.impl.util.SOAPUtil.newSOAPFaultException(SOAPUtil.java:175)
at com.sun.xml.wss.impl.callback.CertificateValidationCallback.getResult(CertificateValidationCallback.java:90)
at com.sun.xml.wss.impl.misc.DefaultSecurityEnvironmentImpl.validateCertificate(DefaultSecurityEnvironmentImpl.java:813)
at com.sun.xml.ws.security.opt.impl.incoming.X509BinarySecurityToken.validate(X509BinarySecurityToken.java:185)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:423)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:296)
at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:245)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.verifyInboundMessage(SecurityTubeBase.java:455)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientResponsePacket(SecurityClientTube.java:434)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:362)
... 11 more
Caused by: com.sun.xml.wss.impl.callback.CertificateValidationCallback$CertificateValidationException: Path does not chain with any of the trust anchors
at com.sun.xml.wss.impl.misc.DefaultCallbackHandler$X509CertificateValidatorImpl.validate(DefaultCallbackHandler.java:1715)
at com.sun.xml.wss.impl.callback.CertificateValidationCallback.getResult(CertificateValidationCallback.java:87)
... 19 more
Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:208)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:279)
at com.sun.xml.wss.impl.misc.DefaultCallbackHandler$X509CertificateValidatorImpl.validate(DefaultCallbackHandler.java:1712)
... 20 more



 Comments   
Comment by Sreekanth [ 03/May/13 ]

Assigning it to MartinG

Comment by Sreekanth [ 03/May/13 ]

Fixed. Issue with the test framework for windows8. Committed the changes in test workspace.





[GLASSFISH-20168] Inline XSD into generated WSDL Created: 04/Apr/13  Updated: 18/Dec/13

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kovica Assignee: Martin Grebac
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: generator, glassfish, webservices, wsdl

 Description   

Generated web service WSDL (http://localhost:8080/Test/TestWS?wsdl) always contains this snippet:
<types>
<xsd:schema>
<xsd:import namespace="http://example.com/" schemaLocation="http://localhost:8080/Test/TestWS?xsd=1"/>
</xsd:schema>
</types>

I know that wsgen supports parameter -inlineSchemas that does what I want.
I don't know if it is possible to configure glassfish to use -inlineScuemas while generating WSDL, but it would sure be great.



 Comments   
Comment by eganya [ 18/Dec/13 ]

Hope to have some news about this issue, if wsgen has to add the inlineSchemas option, it must be too in glassfish console or somewhere, at least show it as the original wsdl generated by wsgen, if i generete the wsdl with -inllineSchema and then deploy to glassfish it shows it with the imports to the xsd..





[GLASSFISH-20082] wrong WSDL used if service and client are in the same module Created: 27/Mar/13  Updated: 19/Sep/14  Resolved: 22/May/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Lukas Jungmann Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JSR-109, section 4.2.2:

For co-located clients (where the client and the server are in the same Java EE application unit) with
generated Service class, the location of the final WSDL document is resolved by comparing the Service name
on the @WebServiceClient annotation on the the generated Service to the Service names of all the deployed
port components in the Java EE application unit. This default behavior can be overridden using the <port-component-link> deployment descriptor element

this use-case does not seem to be supported properly

stacktrace for '@WebServiceRef private WsSei ws':

SEVERE:   Class must be annotated with a interface javax.xml.ws.WebServiceClient annotation
 symbol : interface javax.xml.ws.WebServiceClient
 location: class wsq.Ws1
SEVERE:   Annotations processing failed for file:/home/lukas/NetBeansProjects/WebApplication4/build/web/
INFO:   Webservice Endpoint deployed Ws1
 listening at address at http://lukas-ubuntu:8080/WebApplication4/Ws1.
SEVERE:   Unsupported deployment descriptors element srv.NewServlet/ws value com.sun.enterprise.deploy.shared.FileArchive@7c4ebd2c.
SEVERE:   Exception while invoking class com.sun.enterprise.web.WebDeployer prepare method
SEVERE:   java.lang.RuntimeException
	at org.glassfish.javaee.core.deployment.JavaEEDeployer.prepare(JavaEEDeployer.java:229)
...
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
...
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:290)
	at com.sun.enterprise.deployment.util.ModuleContentLinker.accept(ModuleContentLinker.java:96)
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:852)
	at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
	at org.glassfish.web.deployment.descriptor.WebBundleDescriptorImpl.visit(WebBundleDescriptorImpl.java:1958)
	at org.glassfish.web.deployment.descriptor.WebBundleDescriptorImpl.visit(WebBundleDescriptorImpl.java:1948)
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:844)
	at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.run(JaxRpcRICodegen.java:161)
	at org.glassfish.webservices.JAXRPCCodeGenFacadeImpl.run(JAXRPCCodeGenFacadeImpl.java:60)
	at org.glassfish.javaee.core.deployment.JavaEEDeployer.prepare(JavaEEDeployer.java:218)
	... 35 more
Caused by: java.lang.NullPointerException
	at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGenericServiceInterface(ServiceReferenceDescriptor.java:277)
	at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGeneratedServiceInterface(ServiceReferenceDescriptor.java:281)
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:233)
	... 45 more
...
SEVERE:   Exception while preparing the app
java.lang.RuntimeException
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:290)
	at com.sun.enterprise.deployment.util.ModuleContentLinker.accept(ModuleContentLinker.java:96)
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:852)
	at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
	at org.glassfish.web.deployment.descriptor.WebBundleDescriptorImpl.visit(WebBundleDescriptorImpl.java:1958)
	at org.glassfish.web.deployment.descriptor.WebBundleDescriptorImpl.visit(WebBundleDescriptorImpl.java:1948)
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:844)
	at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.run(JaxRpcRICodegen.java:161)
	at org.glassfish.webservices.JAXRPCCodeGenFacadeImpl.run(JAXRPCCodeGenFacadeImpl.java:60)
	at org.glassfish.javaee.core.deployment.JavaEEDeployer.prepare(JavaEEDeployer.java:218)
...
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NullPointerException
	at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGenericServiceInterface(ServiceReferenceDescriptor.java:277)
	at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGeneratedServiceInterface(ServiceReferenceDescriptor.java:281)
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:233)
	... 45 more

stacktrace for '@WebServiceRef(value=WsImpl.class) private WsSei ws' (where WsImpl class contains @WebServiceClient annotation with missing wsdlLocation):

INFO:   ** BatchRuntimeHelper:: App Undeployed: web
INFO:   Webservice Endpoint deployed Ws1
 listening at address at http://lukas-ubuntu:8080/WebApplication4/Ws1.
INFO:   Loading application [WebApplication4] at [/WebApplication4]
INFO:   WebApplication4 was successfully deployed in 659 milliseconds.
WARNING:   Following exception was thrown:
java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
	at org.glassfish.webservices.WebServiceReferenceManagerImpl.initiateInstance(WebServiceReferenceManagerImpl.java:319)
	at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:142)
	at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:1069)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:745)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
	at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:161)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:613)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:484)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:170)
	at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134)
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:96)
	at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:321)
	at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:266)
	at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:485)
	at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:439)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:313)
	at com.sun.enterprise.web.WebContainer.createServletInstance(WebContainer.java:984)
	at com.sun.enterprise.web.WebModule.createServletInstance(WebModule.java:2130)
...
	at java.lang.Thread.run(Thread.java:722)
Caused by: com.sun.xml.ws.streaming.XMLStreamReaderException: XML reader error: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 'i' (code 105) in prolog; expected '<'
 at [row,col,system-id]: [1,1,"file:/home/lukas/NetBeansProjects/WebApplication4/build/web/"]
	at com.sun.xml.ws.streaming.XMLStreamReaderUtil.wrapException(XMLStreamReaderUtil.java:326)
	at com.sun.xml.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:99)
	at com.sun.xml.ws.streaming.XMLStreamReaderUtil.nextContent(XMLStreamReaderUtil.java:169)
...
	at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:359)
	at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:321)
	at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:230)
	at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:212)
	at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:208)
	at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:112)
	at javax.xml.ws.Service.<init>(Service.java:92)
	at wsq.Ws1Client.<init>(Ws1Client.java:55)
	... 55 more
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 'i' (code 105) in prolog; expected '<'
 at [row,col,system-id]: [1,1,"file:/home/lukas/NetBeansProjects/WebApplication4/build/web/"]
	at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:639)
	at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2032)
	at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1117)
	at com.sun.xml.ws.util.xml.XMLStreamReaderFilter.next(XMLStreamReaderFilter.java:96)
	at com.sun.xml.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:80)
	... 69 more

INFO:   WebModule[null] ServletContext.log():Marking servlet NewServlet as unavailable
WARNING:   StandardWrapperValve[NewServlet]: Allocate exception for servlet NewServlet
com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 'i' (code 105) in prolog; expected '<'
 at [row,col,system-id]: [1,1,"file:/home/lukas/NetBeansProjects/WebApplication4/build/web/"]
	at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:639)
	at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2032)
...
	at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:359)
	at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:321)
	at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:230)
	at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:212)
	at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:208)
	at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:112)
	at javax.xml.ws.Service.<init>(Service.java:92)
	at wsq.Ws1Client.<init>(Ws1Client.java:55)
...
	at org.glassfish.webservices.WebServiceReferenceManagerImpl.initiateInstance(WebServiceReferenceManagerImpl.java:319)
	at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:142)
	at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:1069)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:745)
	at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:715)
	at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:161)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:613)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:484)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:170)
	at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134)
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:96)
	at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:321)
	at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:266)
	at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:485)
	at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:439)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:313)
	at com.sun.enterprise.web.WebContainer.createServletInstance(WebContainer.java:984)
...
	at java.lang.Thread.run(Thread.java:722)


 Comments   
Comment by Lukas Jungmann [ 22/May/13 ]

https://java.net/projects/glassfish/sources/svn/revision/62059





[GLASSFISH-20018] NPE at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGenericServiceInterface(ServiceReferenceDescriptor.java:277) Created: 24/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b85

Type: Bug Priority: Blocker
Reporter: jjsnyder83 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved

 Description   

This is causing CDI tck failure.

A WebSerficeRef is defined like so:
@WebServiceRef
public SheepWS sheepWS;

WebServiceRefHandler.processAWsRef is constructing ServiceReferenceDescriptor via the no-arg constructor (line 234). Later at line 322 wsclientAnn is null which is causing a AnnotationProcessorException to be thrown. This exception is not caught anywhere and so eventually ServiceReferenceDescriptor.hasGenericServiceInterface is called causing the NPE. Here's the stack trace:

[2013-03-24T15:34:26.403-0400] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=44 _ThreadName=Thread-4] [timeMillis: 1364153666403] [levelValue: 1000] [[
java.lang.RuntimeException
at org.glassfish.javaee.core.deployment.JavaEEDeployer.prepare(JavaEEDeployer.java:229)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:922)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:431)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Unknown Source)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:235)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:257)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:329)
at org.glassfish.admin.rest.resources.TemplateListOfResource.post(TemplateListOfResource.java:164)
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.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:350)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:345)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:214)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:207)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:203)
at org.glassfish.jersey.internal.Errors.process(Errors.java:251)
at org.glassfish.jersey.internal.Errors.process(Errors.java:233)
at org.glassfish.jersey.internal.Errors.process(Errors.java:203)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:190)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:865)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:318)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException
at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:290)
at com.sun.enterprise.deployment.util.ModuleContentLinker.accept(ModuleContentLinker.java:96)
at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:852)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
at org.glassfish.web.deployment.descriptor.WebBundleDescriptorImpl.visit(WebBundleDescriptorImpl.java:1958)
at org.glassfish.web.deployment.descriptor.WebBundleDescriptorImpl.visit(WebBundleDescriptorImpl.java:1948)
at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:844)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:621)
at org.glassfish.webservices.codegen.JaxRpcRICodegen.run(JaxRpcRICodegen.java:161)
at org.glassfish.webservices.JAXRPCCodeGenFacadeImpl.run(JAXRPCCodeGenFacadeImpl.java:60)
at org.glassfish.javaee.core.deployment.JavaEEDeployer.prepare(JavaEEDeployer.java:218)
... 59 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGenericServiceInterface(ServiceReferenceDescriptor.java:277)
at com.sun.enterprise.deployment.ServiceReferenceDescriptor.hasGeneratedServiceInterface(ServiceReferenceDescriptor.java:281)
at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:233)
... 69 more]]



 Comments   
Comment by Lukas Jungmann [ 25/Mar/13 ]

Can you share full test case with me, ie via email, or point me to the sources at github, please?
Thanks!

Comment by Lukas Jungmann [ 25/Mar/13 ]

got failing CDI TCK test from JJ and based on the first look and JSR-224, section 7.9 (pages 100-101) it is likely that the test is expecting undefined behaviour. But will double check.

Comment by Lukas Jungmann [ 27/Mar/13 ]

SheepWS is not a class annotated with @WebServiceClient nor the @WebServiceRef.value is defined for the field.

during deployment there are also following warnings:

SEVERE:   Class must be annotated with a interface javax.xml.ws.WebServiceClient annotation
 symbol : interface javax.xml.ws.WebServiceClient
 location: interface org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWS
SEVERE:   Class must be annotated with a interface javax.xml.ws.WebServiceClient annotation
 symbol : interface javax.xml.ws.WebServiceClient
 location: interface org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWS
SEVERE:   Annotations processing failed for file:/home/lukas/NetBeansProjects/WebApplication3/build/web/
SEVERE:   Unsupported deployment descriptors element org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSProducer/sheepWS value com.sun.enterprise.deploy.shared.FileArchive@15fbbf77.
S
Comment by Lukas Jungmann [ 11/Apr/13 ]

cause and fix lies in web services area only

Comment by Lukas Jungmann [ 11/Apr/13 ]
  • What is the impact on the customer of the bug?
    will see failing CDI TCK test
  • How likely is it that a customer will see the bug and how serious is the bug?
    whenever he tries to have web service and its client in the same application unit - this is not recommended but allowed by JSR-109
  • What CTS failures are caused by this bug?
    none
  • What is the cost/risk of fixing the bug?
    the fix is available
  • Is there an impact on documentation or message strings?
    no
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    reqular web services related tests, CTS
  • Which is the targeted build of 4.0 for this fix?
    4.0_b85
  • If this an integration of a new version of a component from another project?
    no
Comment by Lukas Jungmann [ 11/Apr/13 ]

http://java.net/projects/glassfish/sources/svn/revision/61363





[GLASSFISH-19666] jaxb-extra-osgi.jar bundle does not resolve Created: 12/Feb/13  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b74
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Trying to resolve this bundle leads to following exception:

[#|2013-02-12T20:12:47.469+0530|SEVERE|glassfish 4.0|javax.enterprise.logging.stderr|_ThreadID=11;_ThreadName=FelixStartLevel;_TimeMillis=1360680167469;_LevelValue=1000;|org.osgi.framework.BundleException: Unresolved constraint in bundle com.sun.xml.bind.extra [48]: Unable to resolve 48.0: missing requirement [48.0] osgi.wiring.package; (osgi.wiring.package=org.apache.xml.resolver)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3962)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2025)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1279)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:722)

#]

To reproduce, do the following:

asadmin osgi lb -l | grep jaxb-extra-osgi.jar #note the bundle id
asadmin start -t <above bundle id>



 Comments   
Comment by Martin Grebac [ 12/Feb/13 ]

Yardo, please look into this.

Comment by Iaroslav Savytskyi [ 06/Mar/13 ]

Fixed with JAXB 2.2.7-b60 release.





[GLASSFISH-19659] SEVERE: component referenced from annotation symbol cannot be found symbol: javax.jws.HandlerChain Created: 08/Feb/13  Updated: 03/Nov/13  Resolved: 09/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b74

Type: Bug Priority: Major
Reporter: bugs6891 Assignee: Lukas Jungmann
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

windows
NetBeans 7.2.1


Issue Links:
Related
is related to GLASSFISH-16875 Deploying webservice with HandlerChai... Resolved

 Description   

SEVERE: component referenced from annotation symbol cannot be found
symbol: javax.jws.HandlerChain
location: class oprah.oprah

SAME ISSUE:
http://stackoverflow.com/questions/8192712/jax-ws-glassfish-and-handlerchain

--------------------------------------------
oprah/oprah.java
--------------------------------------------
package oprah;

import javax.jws.HandlerChain;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;

@WebService(serviceName = "oprahretina", portName="ServerInfoPort777")
@HandlerChain(file="handler.xml")
public class oprah {

@WebMethod(operationName = "hello")
public String hello(@WebParam(name = "name") String txt)

{ return "Hello " + txt + " !"; }

}

--------------------------------------------
oprah/handler.xml
--------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<handler-chains xmlns="http://java.sun.com/xml/ns/javaee">
<handler-chain>
<handler>
<handler-name>oprah.Hand</handler-name>
<handler-class>oprah.Hand</handler-class>
</handler>
</handler-chain>
</handler-chains>

--------------------------------------------
Hand.java
--------------------------------------------
package oprah;

import java.util.Set;
import javax.xml.ws.handler.MessageContext;
import javax.xml.ws.handler.soap.SOAPHandler;

public class Hand implements SOAPHandler {
@Override
public Set getHeaders()

{ return null; }

@Override
public boolean handleMessage(MessageContext context)

{ System.out.println("hhhhhhhhhhhhhhhhhhhhhh"); return true; }

@Override
public boolean handleFault(MessageContext context)

{ return true; }

@Override
public void close(MessageContext context) {
}
}



 Comments   
Comment by bugs6891 [ 08/Feb/13 ]

Similar issue:

CONNECT Gateway
GATEWAY-1104

HIEM deployment failure with Metro 2.1.1 with component not found errors

Comment by bugs6891 [ 08/Feb/13 ]

This part of code is most probalby throwing it:

package com.sun.enterprise.deployment.annotation.handlers;

public class HandlerChainHandler extends AbstractHandler {

HandlerChainContainer[] containers=null;
if (annCtx instanceof HandlerContext)

{ containers = ((HandlerContext) annCtx).getHandlerChainContainers(serviceSideChain, declaringClass); }

if (containers==null || containers.length==0)

{ // could not find my web service... throw new AnnotationProcessorException( localStrings.getLocalString( "enterprise.deployment.annotation.handlers.componentnotfound", "component referenced from annotation symbol cannot be found"), annInfo); }

http://kickjava.com/src/com/sun/enterprise/deployment/annotation/handlers/HandlerChainHandler.java.htm
Read more: http://kickjava.com/src/com/sun/enterprise/deployment/annotation/handlers/HandlerChainHandler.java.htm#ixzz2KLUlHGlt

Comment by bugs6891 [ 08/Feb/13 ]

This SEVERE messages occure during deployement phase.

Comment by Lukas Jungmann [ 09/Feb/13 ]

reproduced in 3.1.2.2 but cannot reproduce in latest trunk, so looks like this one is fixed. Can you verify it in some trunk build, please?

Thanks.

Comment by bugs6891 [ 09/Feb/13 ]

I have tested it on:
GlassFish Server Open Source Edition 3.1.2.2 (build 5)

Plese tell me if i have done some silly thing.

and it is still there:

[#|2013-02-09T20:18:19.733+0100|SEVERE|glassfish3.1.2|global|_ThreadID=87;_ThreadName=Thread-2;|component referenced from annotation symbol cannot be found
symbol: javax.jws.HandlerChain
location: class oprah.oprah|#]

I am not sure in which version is glassfish under development now, or how to get it.

Comment by Lukas Jungmann [ 09/Feb/13 ]

promoted builds from trunk are available at http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/ latest one at this point is b74, simply grab one called 'latest-'

Comment by bugs6891 [ 09/Feb/13 ]

Nice, thank you very much. This helped me a lot.

(SEVERE|glassfish3.1.2|global|_ThreadID=87;_ThreadName=Thread-2;|component referenced from annotation symbol cannot be found
symbol: javax.jws.HandlerChain)

Message has gone. Superb Lukas. Thank you again.

So I can, definitely say that it is fixed.

(Can i ask next next begginer question, but i do not want to waste your time:
It was fixed on:
GlassFish Server Open Source Edition 4.0 (build 73)

But it was present here (this is some kind of stable release):
GlassFish Server Open Source Edition 3.1.2.2 (build 5)

Is this 4.0 (build 73) version development(beta verion) or some stable(usable)?
)

Comment by Lukas Jungmann [ 09/Feb/13 ]

it could have been fixed earlier

v 3.1.2.2 is the latest released version, it's based on 3.1.2, I don't know about if next patch release is planned or not but you can get paid support for this codeline if needed

v 4.0 is upcoming release, currently under development and is planned to be released sometimes this year;
there are 2 kinds of builds available for it:
-nightly (~daily) builds: http://dlc.sun.com.edgesuite.net/glassfish/4.0/nightly/
-promoted (~weekly) builds: http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/

There are also milestones (~4-6weeks), detailed dates are https://wikis.oracle.com/display/GlassFish/4.0BuildSchedule

wrt stability - promoted builds should be fine to use for development and I'd recommend it, for production - hard to say as some areas are already better than in 3.1.x but others are still under development, so if your app is critical, it's probably better to stick with 3.1.2.2 for now and use v4 for testing

HTH

Comment by abhi0123 [ 03/Nov/13 ]

I'm seeing this on glassfish-4.0-b89 and came across this thread. It is obviously not fixed yet. As others have noted, the handler chain actually gets invoked but that doesn't make the message any less annoying. Will attach working code if someone wants to take a look.

[2013-11-03T15:44:44.452-0500] [glassfish 4.0] [SEVERE] [] [global] [tid: _ThreadID=36 _ThreadName=admin-listener(5)] [timeMillis: 1383511484452] [levelValue: 1000] [[
  Component referenced from annotation symbol cannot be found
 symbol: javax.jws.HandlerChain
 location: class name.abhijitsarkar.learning.webservices.jaxws.security.ut.CalculatorUT]]

(Also posted on https://java.net/jira/browse/GLASSFISH-16875)





[GLASSFISH-19619] NPE while writing out descriptors Created: 01/Feb/13  Updated: 08/Feb/13  Resolved: 08/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.0_b74

Type: Bug Priority: Critical
Reporter: Lukas Jungmann Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
  • have a war with a webservice, servlet, web.xml and glassfish-web.xml (I can send app if needed)
  • add '-Dwriteout.xml=true' jvm option to GF
  • deploy app

=>

java.lang.NullPointerException
	at com.sun.enterprise.deployment.util.DOLUtils.sortConfigurationDDFiles(DOLUtils.java:315)
	at com.sun.enterprise.deployment.util.DOLUtils.processConfigurationDDFiles(DOLUtils.java:401)
	at com.sun.enterprise.deployment.archivist.ExtensionsArchivist.getSortedConfigurationDDFiles(ExtensionsArchivist.java:269)
	at com.sun.enterprise.deployment.archivist.ExtensionsArchivist.writeRuntimeDeploymentDescriptors(ExtensionsArchivist.java:254)
	at com.sun.enterprise.deployment.archivist.ExtensionsArchivist.writeDeploymentDescriptors(ExtensionsArchivist.java:226)
	at org.glassfish.webservices.archivist.WebServicesArchivist.writeDeploymentDescriptors(WebServicesArchivist.java:123)
	at com.sun.enterprise.deployment.archivist.Archivist.writeExtensionDeploymentDescriptors(Archivist.java:925)
	at com.sun.enterprise.deployment.archivist.Archivist.writeDeploymentDescriptors(Archivist.java:865)
	at com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:109)
	at com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:81)
	at org.glassfish.javaee.core.deployment.DolProvider.saveAppDescriptor(DolProvider.java:388)
	at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:226)
	at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:879)
...


 Comments   
Comment by Hong Zhang [ 01/Feb/13 ]

Yes, please send the test application to me by email. Thanks!

Comment by Hong Zhang [ 04/Feb/13 ]

I am seeing a different error than you when trying to deploy the application:

[#|2013-02-04T13:00:27.104-0500|SEVERE|glassfish 4.0|javax.enterprise.system.core|_ThreadID=80;_ThreadName=admin-listener(1);_TimeMillis=1360000827104;_LevelValue=1000;_MessageID=NCLS-CORE-0026;|Exception during lifecycle processing
java.lang.NullPointerException
at com.sun.enterprise.deployment.node.runtime.WebServiceEndpointRuntimeNode.setElementValue(WebServiceEndpointRuntimeNode.java:127)
at com.sun.enterprise.deployment.node.SaxParserHandler.endElement(SaxParserHandler.java:617)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:606)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:266)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2005)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:879)

Can you please look into that first? Thanks.

Comment by Lukas Jungmann [ 08/Feb/13 ]

http://java.net/projects/glassfish/sources/svn/revision/59313





[GLASSFISH-19611] soap:address always appends :80 regardless of settings when using AJP Created: 31/Jan/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: clambertus Assignee: Lukas Jungmann
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 12.04.1, apache-2.2.22-1ubuntu1.2



 Description   

I utilize a series of SSL hosts along with mod_proxy_ajp to push application traffic to Glassfish 3's AJP listener.

When I deploy an EJB service, the generated WSDL contains https://my.server.name:80/ServiceName. The appending of port :80 breaks the service call, because it's attempting to connect to an https URL via port 80. This worked in GF2, in that the soap:address location contains an appended :443 as expected.

I have attempted all means that I am aware of to force a static WSDL (using wsdlLocation="" in my @WebService definition), or by attempting to force wsdl-port in sun-ejb-jar.xml, but the autogenerated soap:address location="" always contains the appended :80.

I have modified server name parameters in the various listener defininitions in domain.xml to no avail.

I would like for this to append :443 instead of :80 for autogenerated WSDLs when accessed via AJP proxied https://. Alternately, I would like for a static WSDL to override the autogenerated soap:address, which it does not appear to do currently.

Am I doing something wrong, or is this an issue with AJP and WSDL autogeneration? It would also work if NO port were appended for AJP connections, instead of port 80, so if there are any ways to accomplish this, please let me know.

I am willing and able to test any ideas/solutiions/etc.

Thanks for the support!



 Comments   
Comment by Peter Salomonsen [ 24/Apr/13 ]

I experience exactly the same. I have a working configuration with Apache HTTPS in front of Glassfish 2 using AJP. When setting up the same in Glassfish 3 the generated WSDL points to port 80 - where GF2 points to 443. I've tested with various configuration parameters both for Apache and GF3, but it still keeps pointing to :80. At this point it seems to be a show stopper for migrating web apps with secure web services using AJP to GF3.

Comment by Lukas Jungmann [ 24/Apr/13 ]

can you try it with latest glassfish4[1] and let me know the result, please?

Thank you!

[1]: you can find latest promoted build at http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/

Comment by Peter Salomonsen [ 24/Apr/13 ]

Just tested with GlassFish Server Open Source Edition 4.0 (build 85) - and it works as it should (the wsdl shows port 443).

Will this be fixed for GF3? I had other problems when trying to deploy on GF4 (JMS/MDB components failed) - so I guess it's not safe to start using GF4 at this point?

Comment by Lukas Jungmann [ 24/Apr/13 ]

Closing as fixed in 4.0 then. Thanks for checking this, Peter!

Unfortunately, it is unlikely this will be fixed in v3 through this channel as v4 is current development branch.





[GLASSFISH-19559] asadmin deploy failed Created: 21/Jan/13  Updated: 23/Jan/13  Resolved: 22/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.0_b72_EE7MS4

Type: Bug Priority: Major
Reporter: xianwu Assignee: Lukas Jungmann
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Issue Links:
Related
is related to GLASSFISH-18743 Webservice deploy error message when ... Resolved

 Description   

Reproducible operational steps:
asadmin.bat deploy --target server TestApp.war

Detailed description of the issue:
The deploy command failed with errors below

C:\Projects\TRAC\5283>asadmin deploy --target server TestApp.war
remote failure: Error occurred during deployment: Exception while preparing the
app : Servlet TestWebImpl implements 2 web service endpoints but must only impl
ement 1. Please see server.log for more details.
Command deploy failed.

The testing was under GlassFish v4 trunk (built from https://svn.java.net/svn/glassfish~svn/trunk (revision 57288))



 Comments   
Comment by xianwu [ 21/Jan/13 ]

Hi Martin

I am unable to attach the sample application TestApp.war.
I guess that I don't have a permission to do so.

Can you please provide help for me to attach the file?

Regards, Xianwu

Comment by Martin Grebac [ 21/Jan/13 ]

Hi, you can e.g. publish the file somewhere else and provide pointer.

Comment by xianwu [ 21/Jan/13 ]

Hi Lukas,

We don't have a repository for me to upload the required attachment for the bug report.

Can you please provide your email then I can send the attachment to you?

Regards, Xianwu

Comment by xianwu [ 22/Jan/13 ]

Hi Martin, Lukas

I have uploaded TestApp.war to github at

https://github.com/xianwum/GLASSFISH-19559/blob/master/TestApp.war

Can you please investigate it?

PS. I can deploy TestApp.war to tomcat (apache-tomcat-6.0.35) without error.

Regards, Xianwu

Comment by Lukas Jungmann [ 22/Jan/13 ]

there's a mismatch between port-component-name found in annotations (resolves to TestWebImpl) and port-component-name defined in webservices.xml (there's TestWeb) - so if these values match (ie entry in webservices.xml is changed from TestWeb to TestWebImpl), application deploys fine - I need to check the spec to see what is correct behaviour...

Comment by Lukas Jungmann [ 22/Jan/13 ]

current behaviour is as designed - port-component-name is defined by the javaee_web_services_1_2.xsd schema as the name of the service implementation bean which is, in this case, "TestWebImpl".

Comment by xianwu [ 23/Jan/13 ]

Hi Lukas

Thanks for your investigation.
I have questions about your previous comments regarding definition of port-component-name.

1) You have comment below
"there's a mismatch between port-component-name found in annotations (resolves to TestWebImpl) and port-component-name defined in webservices.xml (there's TestWeb) - so if these values match (ie entry in webservices.xml is changed from TestWeb to TestWebImpl), application deploys fine - I need to check the spec to see what is correct behaviour"

However, based on guideline below by IBM (http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftwbs_jaxwsdeploydescriptor.html),

"Deployment descriptors are standard text files, formatted using XML and packaged in a Web services application. You can optionally use the webservices.xml deployment descriptor to augment or override application metadata specified in annotations within Java API for XML-Based Web Services (JAX-WS) Web services."

webservices.xml can override whatever annotations in Java class.
So, your comments about mismatch between port-component-name in webservices.xml and annotations may not be correct.

2) You have comment below
"current behaviour is as designed - port-component-name is defined by the javaee_web_services_1_2.xsd schema as the name of the service implementation bean which is, in this case, "TestWebImpl""

I don't quite agree with your comment.

Here is the description from javaee_web_services_1_2.xsd

"The port-component-name element specifies a port
component's name. This name is assigned by the module
producer to name the service implementation bean in the
module's deployment descriptor. The name must be unique
among the port component names defined in the same module.

Used in: port-component

Example:
<port-component-name>EmployeeService
</port-component-name>"

First, I failed to figure out from the above description that the "port-component-name" must match the name of service implementation bean.
What I understand is to specify a whatever name you like but it must be unique in the same module.

Second, it won't make "port-component-name" unique if the port-component-name is from the name of service implementation bean.
Here is a scenario.
In webservices.xml, we have multiple port-components. Two of them have the same name of the service implementation bean (with different package name).
Based on the schema, you can't use the name of service implementation bean as port-component-name for both.

Can you please continue investigate?

Regards, Xianwu

Comment by Lukas Jungmann [ 23/Jan/13 ]

Hi Xianwu,

ok, perhaps the very basic question here should be what are you trying to achieve?

in your application, there you have:

  • service endpoint interface (SEI)
  • service implementation bean (SIB) (side note: be aware that @WebService.name must not be here if endpointInterface is used)
  • entries in web.xml (which are optional)
  • webservices.xml (optional)

where SEI+SIB+web.xml define a web service with port name 'TestWebImpl'
and webservices.xml defines a web service with port name 'TestWeb'

during deployment on glassfish these two sources are merged together and problem appears (as you originally reported):

"Servlet TestWebImpl implements 2 web service endpoints but must only impl
ement 1" - this error message during deployment means that both services - 'TestWeb' and 'TestWebImpl' - are implemented by the same class

re 1) "...You can optionally use the webservices.xml deployment descriptor to augment or override application metadata specified in annotations..." absolutely, this is true but how can GlassFish know you want to override some annotations if you don't link these descriptors together? GlassFish uses port-component-name for this (defaults to SIB name or SIB FQN if there's a conflict)

re 2) That definition should not clash with what I've said for the case of overriding annotations, IMHO. It depends on use-case: are you overriding existing service (defined by annotations) or defining a new one (ie old JAX-RPC one)?

"I failed to figure out ... that the "port-component-name" must match the name of service implementation bean." - well, if you want to override what's defined in annotations - yes, this should match, at least for GlassFish;

re uniqueness - if there's a conflict in port-component-name then fully qualified name of the SIB should be used instead

--lukas

Comment by xianwu [ 23/Jan/13 ]

Hi Lukas

Thanks for your investigation.

I am not here to argue with you about right or wrong of your comments.
The whole purpose is to determine if it is a GF bug.

From the error message, we know that during the deployment,
GF has figured out there are two services 'TestWeb' and 'TestWebImpl' implemented by the same class.
'TestWeb' is defined in webservices.xml while 'TestWebImpl' is implicitly mapped by GF from annotation.

Now the questions are
1) should GF override 'TestWebImpl' (by annotation) with 'TestWeb' (by webservices.xml)?
2) should GF merge the 'TestWebImpl' (by annotation) and 'TestWeb' (by webservices.xml)?

If yes to 1), this issue is a GF bug.
If yes to 2), GF should document this limitation/behavior somewhere then users can avoid this error.

Regards, Xianwu

Comment by Lukas Jungmann [ 23/Jan/13 ]

Hi Xianwu,

re 1) no
re 2) no, it should merge info from annotations and deployment descriptors (unless metadata-complete="true" is set in web.xml); for this case there will be 2 definitions (IDs do not match => no override happens)

regards,
--lukas

Comment by xianwu [ 23/Jan/13 ]

Hi Lukas,

Thanks for your clarification.

Regards, Xianwu





[GLASSFISH-19493] CDI dependency injection fails for JAXWS handler classes Created: 04/Jan/13  Updated: 17/Dec/13  Resolved: 26/Mar/13

Status: Resolved
Project: glassfish
Component/s: cdi, web_services
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: tomkri Assignee: arjavdesai
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04.1 64bit
Oracle JDK 1.7.0.10


Tags: cdi, jaxws

 Description   

The Java EE 6 specification lists JAXWS handlers as component classes that are supporting injection (see page 69, table EE.5-1).

It seams, that within Glassfish 3.1.2.2 (build 5) @Inject is not resolved for handler classes. Is this a known bug?

I have found a forum posting (http://forums.java.net/node/873115) that has not been answered yet.

The attached sample demonstrates this issue.

  • ServerSideTicketHandler is a JAXWS handler that has dependency to TicketFactory (should be resolved via @Inject). Since DI does not work "ticketFactory is null" is logged to System.out.
  • ProductServiceEndpoint is the service implementation that itself delegates the method call to ProductRepository (here @Inject works as expected).


 Comments   
Comment by arjavdesai [ 05/Mar/13 ]

tomkri,

I don't see the attachment. Can you please upload the same?

thanks!

Comment by arjavdesai [ 26/Mar/13 ]

Revision 60836 should fix the issue.

Comment by DimitriJakov [ 17/Dec/13 ]

Unfortunately, injection still does not work for handlers attached to web service clients via @HandlerChain annotation and XML file (at least). The mechanism for their instantiation is different from that of endpoints. See com/sun/xml/ws/handler/HandlerChainsModel.java:272:

handler = (Handler) loadClass(classLoader,
    XMLStreamReaderUtil.getElementText(reader).trim()).newInstance();

Seems like handlers are simply instantiated, with no signs of injections being processed.

If needed, I can supply a MWE and a stack trace to demonstrate the issue. (GlassFish v4.0 build 89, Oracle JDK 1.7.0_45)





[GLASSFISH-19432] asadmin deploy provides a misleading error message Created: 12/Dec/12  Updated: 15/Jan/13  Resolved: 15/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.0_b72_EE7MS4

Type: Bug Priority: Major
Reporter: xianwu Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: File jaxws-w2j-02-web.war    
Issue Links:
Related
is related to GLASSFISH-19366 GlassFish fails to deploy a JAX-WS se... Resolved

 Description   

Reproducible operational steps:
asadmin.bat deploy axws-w2j-02-web.war

Detailed description of the issue:
When a war file is deployed by asadmin deploy command, it provided a misleading error message.
asadmin.bat deploy C:\Projects\TRAC\4851\jaxws-w2j-02-web.war
remote failure: Error occurred during deployment: Exception while preparing the
app : Service AddNumbersService seems to be a JAXRPC based web service but without the mandatory WSDL and Mapping file. Deployment cannot proceed. Please see server.log for more details.
Command deploy failed.

In fact, the war file contains valid WSDL and Mapping file although there exist other bugs in the war file.

The testing was under GlassFish v4 trunk (built from https://svn.java.net/svn/glassfish~svn/trunk (revision 57288))



 Comments   
Comment by Hong Zhang [ 12/Dec/12 ]

The error message is from webservices code, assign to webservices team for evaluation.

Comment by Hong Zhang [ 02/Jan/13 ]

Assign to webservice team for evaluation as the error message is from the webservices code (when I previously reassigned it I forgot to change the assigned engineer and only changed category).

Comment by Martin Grebac [ 03/Jan/13 ]

I see - Lukasi - is this WS issue?

Comment by Lukas Jungmann [ 14/Jan/13 ]

yep, this is ours. The real cause is buried in the server side log:

SEVERE: Unable to load impl class fromwsdl.server.AddNumbersImpl
java.lang.ClassNotFoundException: fromwsdl.server.AddNumbersImpl
...
	at org.glassfish.webservices.WsUtil.isJAXWSbasedService(WsUtil.java:744)
	at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:166)

this error should be made critical and sent back to the user instead of allowing further processing. In this sense it is duplicate of GLASSFISH-19366.

The difference between these two issues is the real cause:
*this issue - servlet-class links to non-existing class
*GLASSFISH-19366 - servlet-class element is missing

Comment by Lukas Jungmann [ 15/Jan/13 ]

http://java.net/projects/glassfish/sources/svn/revision/58475





GlassFish services and components to conform with configuration modularity (GLASSFISH-19408)

[GLASSFISH-19414] Web Services related configuration in domain.xml to conform with configuration modularity Created: 06/Dec/12  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.1.1

Type: Sub-task Priority: Major
Reporter: Masoud Kalali Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Different modules/services requires to conform with configuration modularity. This is a parent task for all the issue being filed for this project. More details at the internal wiki page: http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Config+Modularity+One+Pager This ticket is to track this change for web services container/configuration.






[GLASSFISH-19366] GlassFish fails to deploy a JAX-WS service thinking it is a JAXRPC service Created: 22/Nov/12  Updated: 15/Jan/13  Resolved: 15/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b05
Fix Version/s: 4.0_b72_EE7MS4

Type: Bug Priority: Major
Reporter: abhi0123 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8 Professional 64-bit, Eclipse Juno SR 1, Oracle JDK 1.7.0_09, GlassFish 3.1.2.2 (build 5)


Attachments: Zip Archive jaxws-servlet-container.zip    
Issue Links:
Related
is related to GLASSFISH-19432 asadmin deploy provides a misleading ... Resolved
Tags: JAX-WS, JAXRPC, WSDL, mapping, webservice, webservices

 Description   

I am trying to deploy a Servlet based endpoint using a webservices.xml in GlassFish 3.1.2.2. webservices.xml file could be used to augment or override existing JAX-WS annotations. However, GlassFish throws an error:
Service TimeService seems to be a JAXRPC based web service but without the mandatory WSDL and Mapping file. Deployment cannot proceed.

What surprises me is that several people have reported having this problem since GlassFish 2. However no one seems to have created a Jira and no one from the GlassFish Dev team has attempted to fix it.

Maven project attached.



 Comments   
Comment by Lukas Jungmann [ 14/Jan/13 ]

could you attach better testcase (the one I could just execute by 'mvn install' and get the same error you're seeing - current testcase is missing dependencies/parent project, so I can only guess), attach server.log and/or give us pointers to other users having the same problem, please?

based on attached test project I did:
-created new project
-copied sources (*.java, *.xml) from attached testcase to this new project
-deployed application to latest GlassFish 4 (svn rev 58416)

=> failed with following exceptions:

java.lang.ClassNotFoundException:
...
	at org.glassfish.webservices.WsUtil.isJAXWSbasedService(WsUtil.java:744)
	at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:166)
...

Exception while invoking class org.glassfish.webservices.WebServicesDeployer prepare method

java.lang.RuntimeException: Service WsImpl seems to be a JAXRPC based web service but without the mandatory WSDL and Mapping file. Deployment cannot proceed
	at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:186)
...
Caused by: java.lang.RuntimeException: Service WsImpl seems to be a JAXRPC based web service but without the mandatory WSDL and Mapping file. Deployment cannot proceed
	at org.glassfish.webservices.codegen.JaxRpcRICodegen.accept(JaxRpcRICodegen.java:336)
...

-inspected current code and found that there is missing servlet-class element in web.xml which declares itself as metadata-complete
-added servlet-class definition to web.xml and redeployed the app
-created a client and called the service

=> everything worked fine

This implies that this is more of user error then a bug on the GlassFish side.

Anyway I can see one problem here in a quite misleading error message which should say something about a real cause of the problem instead of java.lang.ClassNotFoundException: and allowing further processing

Comment by Lukas Jungmann [ 15/Jan/13 ]

http://java.net/projects/glassfish/sources/svn/revision/58475





[GLASSFISH-19355] Deployment failed - javax.xml.ws .WebServiceException: Unable to create JAXBContext Created: 18/Nov/12  Updated: 07/Jan/13  Resolved: 19/Nov/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: v2.1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: test_java Assignee: Martin Grebac
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris SPARC on 64-Bit



 Description   

I am attempting to upgrade our existing GlassFish that is currently running:
Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs)

to recently released patch set 128647-33 - Sun GlassFish Enterprise Server 2.1.1 Patch19 (v2.1 Patch25) (9.1_02 Patch31)

After installing GlassFish patch, when deploying our web applications, seeing the following error:

[#|2012-11-06T15:14:02.710+0100|INFO|sun-appserver2.1.1|javax.enterprise.system.container.ejb|_ThreadID=81;_ThreadName=Thread-2078;|wsgen successful|#]

[#|2012-11-06T15:14:03.632+0100|WARNING|sun-appserver2.1.1|javax.enterprise.system.stream.err|_ThreadID=81;_ThreadName=Thread-2078;_RequestID=7df157a6-cbeb-44a8-91f6-8251d07076a6;|javax.xml.ws
.WebServiceException: Unable to create JAXBContext
at com.sun.xml.ws.model.AbstractSEIModelImpl.createJAXBContext(AbstractSEIModelImpl.java:164)
at com.sun.xml.ws.model.AbstractSEIModelImpl.postProcess(AbstractSEIModelImpl.java:94)
at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:255)
at com.sun.tools.ws.wscompile.WsgenTool.buildModel(WsgenTool.java:240)
at com.sun.tools.ws.wscompile.WsgenTool.run(WsgenTool.java:123)
at com.sun.tools.ws.util.WSToolsObjectFactoryImpl.wsgen(WSToolsObjectFactoryImpl.java:61)
at com.sun.tools.ws.spi.WSToolsObjectFactory.wsgen(WSToolsObjectFactory.java:107)
at com.sun.enterprise.webservice.WsUtil.runWsGen(WsUtil.java:1846)
at com.sun.enterprise.webservice.WsUtil.genWSInfo(WsUtil.java:2253)
at com.sun.enterprise.deployment.backend.ModuleDeployer.loadDescriptors(ModuleDeployer.java:427)
at com.sun.enterprise.deployment.backend.WebModuleDeployer.deploy(WebModuleDeployer.java:160)
at com.sun.enterprise.deployment.backend.ModuleDeployer.doRequestFinish(ModuleDeployer.java:182)
at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:208)
at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:966)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:283)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:835)
at com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:187)
at com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:225)
Caused by: java.security.PrivilegedActionException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions
java.util.Map is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at java.util.Map
at private java.util.Map com.sel.services.SELReport.jaxws.ReadTReportResponse._return
at com.sel.services.SELReport.jaxws.ReadTReportResponse
java.util.Map does not have a no-arg default constructor.
this problem is related to the following location:
at java.util.Map
at private java.util.Map com.sel.services.SELReport.jaxws.ReadTReportResponse._return
at com.sel.services.SELReport.jaxws.ReadTReportResponse
java.util.Map does not have a no-arg default constructor.
this problem is related to the following location:
at java.util.Map
at private java.util.Map com.sel.services.SELReport.jaxws.ReadTReportResponse._return
at sel.services.SELReport.jaxws.ReadTReportResponse

at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.ws.model.AbstractSEIModelImpl.createJAXBContext(AbstractSEIModelImpl.java:151)
... 18 more
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions
java.util.Map is an interface, and JAXB can't handle interfaces.
this problem is related to the following location:
at java.util.Map
at private java.util.Map com.sel.services.SELReport.jaxws.ReadTReportResponse._return
at com.sel.services.SELReport.jaxws.ReadTReportResponse
java.util.Map does not have a no-arg default constructor.
this problem is related to the following location:
at java.util.Map
at private java.util.Map com.sel.services.SELReport.jaxws.ReadTReportResponse._return
at com.sel.services.SELReport.jaxws.ReadTReportResponse

at com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:102)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:472)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:302)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1140)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:154)
at com.sun.xml.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:106)
at com.sun.xml.ws.developer.JAXBContextFactory$1.createJAXBContext(JAXBContextFactory.java:109)
at com.sun.xml.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:159)
at com.sun.xml.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:152)
... 20 more

#]

-----------

Please can you let me know what could be the issue

Thanks



 Comments   
Comment by Hong Zhang [ 19/Nov/12 ]

The stack trace is from webservices code, assign to webservices team for evaluation.

Comment by Martin Grebac [ 19/Nov/12 ]

I'm not familiar with what changes went into 2.1.1 / p19, but this looks like there are 2 possible causes:

  • there may be change in how web service methods are recognized - you may need to set 'com.sun.xml.ws.model.RuntimeModeler.legacyWebMethod=true' property
  • mismatch of api/impl - you're somehow mixing jaxb api and implementation versions, or started running on a different jdk, ...

So please verify the above, and if you still face the issue feel free to reopen the issue with simple reproducible app so that we can test. Thanks.

Comment by test_java [ 07/Jan/13 ]

Happy New Year!
Sorry for the delay in updating this thread.

Thank you for the response and we corrected by ensuring all the methods other than the webmethod (@WebMethod) should be private.

One more question, does GlassFish ESB v2.2 (2.1.1) does it work/supports Java 7

Thank you

Comment by Martin Grebac [ 07/Jan/13 ]

Hi, I don't think it has been tested, but that would be a question to ESB.

I'm not sure I understand your response though - does it mean the issue is gone after you updated the code to only expose @WebMethod methods, or does it mean you see the issue still - despite the correctio?





[GLASSFISH-19294] Cannot define multiple endpoints for same EJB WS Created: 06/Nov/12  Updated: 12/Feb/13  Resolved: 12/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b05
Fix Version/s: 4.0_b75

Type: Bug Priority: Minor
Reporter: stef_esrf Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Linux version 2.6.32-100.26.2.el5 (mockbuild@ca-build10.us.oracle.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Jan 18 20:11:49 EST 2011


Attachments: File MultEndpntsEAR.ear     Java Source File MultEndpntsWS.java    
Tags: webservice

 Description   

Trying to define two WS endpoints for the same EJB to work around bug GLASSFISH-19293 . None of the two endpoints is created according to specified endpoint-address-uri.

Please see attached test case. The endpoint definitions are:

<ejb>
<ejb-name>MultEndpntsWS</ejb-name>
<webservice-endpoint>
<port-component-name>MultEndpntsWS1</port-component-name>
<endpoint-address-uri>MultEndpntsWSService/MultEndpntsWS1</endpoint-address-uri>
<transport-guarantee>NONE</transport-guarantee>
</webservice-endpoint>
<webservice-endpoint>
<port-component-name>MultEndpntsWS2</port-component-name>
<endpoint-address-uri>MultEndpntsWSService/MultEndpntsWS2</endpoint-address-uri>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</webservice-endpoint>
</ejb>

I can access the wsdl under http://<myserver>:8080/MultEndpntsWSService/MultEndpntsWS?wsdl which seems to be the default URL when no endpoint-address-uri is specified. I cannot access the wsdl under the URLs that I would expect: http://<myserver>:8080/MultEndpntsWSService/MultEndpntsWS1?wsdl and https://<myserver>:8181/MultEndpntsWSService/MultEndpntsWS2?wsdl .

Checking the deployment guide http://docs.oracle.com/cd/E18930_01/html/821-2417/beass.html#scrolltoc this should be possible (element: webservice-endpoint, required: zero or more).

Thanks!



 Comments   
Comment by Lukas Jungmann [ 12/Feb/13 ]

original GLASSFISH-19293 has been already fixed, so this is not needed (it's not supported anyway as port-component-name is defined to be used as a key between EJB and WS endpoint definition hence only one mapping is allowed)





[GLASSFISH-19293] Acessing EJB based WebService over https with transport-guarantee NONE fails Created: 06/Nov/12  Updated: 11/Feb/13  Resolved: 11/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b05
Fix Version/s: 4.0_b75

Type: Bug Priority: Major
Reporter: stef_esrf Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Linux version 2.6.32-100.26.2.el5 (mockbuild@ca-build10.us.oracle.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Jan 18 20:11:49 EST 2011


Attachments: File UnsecureEAR.ear     Java Source File UnsecureService.java    
Tags: webservice

 Description   

WS deployed as EJB and configured with transport-guarantee NONE can be accessed over http but NOT over https. Seems to be linked to former bug GLASSFISH-5621.

This works fine for web applications (jsp). In our case it is important since all external calls come over https through the firewall, apache and mod_jk to our WS, but all local calls contact the WS directly over http.

Please find a test case attached. Accessing the wsdl under http://<myserver>:8080/UnsecureServiceService/UnsecureService?wsdl works fine. If I try https://<myserver>:8181/UnsecureServiceService/UnsecureService?wsdl I get a blank page and the following error in server.log:

[#|2012-11-06T10:57:08.156+0100|WARNING|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=424;_ThreadName=Thread-2;|Invalid request scheme for Endpoint UnsecureService. Expected http . Received https|#]

Thanks!



 Comments   
Comment by Lukas Jungmann [ 11/Feb/13 ]

http://java.net/projects/glassfish/sources/svn/revision/59356





[GLASSFISH-19287] JAXB 1.0 based applications do not work due to JAXB-899 Created: 05/Nov/12  Updated: 17/Jan/13  Resolved: 17/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: bthalmayr Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jaxb, metro-gf3125

 Description   

Having a web-application which uses classes created by JAXB 1.0.x does not run on GF 3.1.2.2 due to bug JAXB-899

Copying stacktrace from JAXB-899

Caused by: javax.xml.bind.JAXBException

  • with linked exception:
    [java.lang.NoSuchFieldError: theInstance]
    at com.sun.xml.bind.ContextFactory_1_0_1.createContext(ContextFactory_1_0_1.java:100)
    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 javax.xml.bind.ContextFinder.newInstance(Unknown Source)
    at javax.xml.bind.ContextFinder.find(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at javax.xml.bind.JAXBContext.newInstance(Unknown Source)
    at mypackage.JAXBContextWrapper.getInstance(JAXBContextWrapper.java:57)
    at mypackage.JAXBObjectWrapper.getUnmarshallerStatic(JAXBObjectWrapper.java:161)
    at mypackage.JAXBObjectWrapper.unmarshalStatic(JAXBObjectWrapper.java:184)
    at mypackage.JAXBObjectWrapper.<init>(JAXBObjectWrapper.java:67)
    ... 11 more
    Caused by: java.lang.NoSuchFieldError: theInstance
    at mypackage.generated.jaxb104.impl.runtime.DefaultJAXBContextImpl.<init>(DefaultJAXBContextImpl.java:50)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at com.sun.xml.bind.ContextFactory_1_0_1.createContext(ContextFactory_1_0_1.java:94)
    ... 24 more


 Comments   
Comment by kumara [ 05/Nov/12 ]

-> web_services because glassfish gets jaxb from metro integration handled through web_services sub component.

Comment by Martin Grebac [ 05/Nov/12 ]

Yarda, please work with Lukas on getting this fixed in a branch for GF 3.1.2.x patch. Thanks.

Comment by bthalmayr [ 05/Nov/12 ]

We try to deliver a JAXB 1.0 based web-application (as we do not have time to migrate it to JAXB 2.0).

As this web-app can be run on fully J2EE compliant container like GF v3 and servlet engines like Tomcat we possibly need to deliver 2 different distro of the application

Old discussion: 'self-contained' vs. 'container-provided' libraries

As JAXB 2.0 should be backward compatible (for all my readings) we actually don't want to bundle any J2EE related libraries with the 'J2EE distro'.

Comment by Martin Grebac [ 07/Nov/12 ]

Yardo, as we're defining jaxb-extra-osgi since metro 2.1.1 for backw. compatibility purposes, I think that would be the right place for jaxb1 as well - what do you think?

Comment by Iaroslav Savytskyi [ 07/Nov/12 ]

Definitely you are right. May be it's also a good idea to mark jaxb-extra-osgi as 'optional' jar.

Comment by Iaroslav Savytskyi [ 21/Nov/12 ]

Hi, all,

as I understand GF 3.1.2.2 uses JAXB 2.2.5.2 which contains JAXB1 classes. So probably problem is somewhere else. We need testcase to reproduce this bug.

Comment by Martin Grebac [ 21/Nov/12 ]

Hi, went again through this more properly - the fix for this went into 2.2.6:

Revision: 3918
Author: snajper
Date: 2012-05-11 15:20:09 UTC
Log Message:
------------
fix for JAXB-899 - keep the jaxb1 required methods, but deprecate all of them + the class -> issue 723 will remain closed because we removed usage of these duplications from the RI2 code and deprecation should (hopefully) make sure we don't start using them again
the whole class should be refactored away eventually in the future - requires little api update since currently it's impossible to reuse the API DTC instead of the RI's one

The bug is not about missing class (thus it is not osgi issue), but about missing theInstance method which was caused as a regression from trying to merge the DTC implementations used in jaxb api/ri. So, I guess the only thing needed is to merge the fix into 2.2.5.x codebase.

Comment by Iaroslav Savytskyi [ 20/Dec/12 ]

Hi,

I've merged 3918 revision to jaxb 2.2.5.3 version.

Comment by Iaroslav Savytskyi [ 17/Jan/13 ]

Should be integrated into 3.1.2.5 GF version.
JAXB SVN revision: 3997





[GLASSFISH-19230] Metro 2.3 for GlassFish 4 Created: 25/Oct/12  Updated: 08/Mar/13  Resolved: 08/Mar/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.0_b80_EE7MS6

Type: New Feature Priority: Major
Reporter: Lukas Jungmann Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

deliver Metro 2.3 for GlassFish 4



 Comments   
Comment by Lukas Jungmann [ 08/Mar/13 ]

waiting for Metro availability in mvn central

Comment by Lukas Jungmann [ 08/Mar/13 ]

http://java.net/projects/glassfish/sources/svn/revision/60237





[GLASSFISH-19229] Fix deployment from JDeveloper issue described in GLASSFISH-3297 Created: 24/Oct/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b59
Fix Version/s: 4.0_b72_EE7MS4

Type: Bug Priority: Major
Reporter: gdavison Assignee: Lukas Jungmann
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File WebServices.war    
Issue Links:
Duplicate
duplicates GLASSFISH-3297 Simple war file doesn't appear to dep... Resolved

 Description   

So I am trying to deploy a simple war file generate by Oracle JDeveloper 11 (Technology Preview) by
placing it in the autodeploy directory.

This war file contains one class:

package org.kingsfleet;

@WebService
public class MathService {
public int thing(int a, int b)

{ return a^b; }

}

With the following web.xml:

<?xml version = '1.0' encoding = 'US-ASCII'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://
java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee">
<description>Empty web.xml file for Web Application</description>
<servlet>
<servlet-name>MathServicePort</servlet-name>
<servlet-class>org.kingsfleet.MathService</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>MathServicePort</servlet-name>
<url-pattern>/mathserviceport</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>35</session-timeout>
</session-config>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>txt</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
</web-app>

When copied to the autodeploy directory I quite quickly see the WebServices.war_deployed signal which
is good. When I try to test my web service using the management console though I get "404 - Resource
not avaliable" when I try to test or view the WSDL for the service. Interestingly I can view the deployment
descriptor okay.

If modify the web.xml to remove all the servlet mappings:

<?xml version = '1.0' encoding = 'US-ASCII'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://
java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee">
<description>Empty web.xml file for Web Application</description>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>txt</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
</web-app>

The service deploys properly.

There is a bug GLASSFISH-3297 that is tracking the inconsistency with the reporting of the deployment status, and this bug is specifically to look at the failure to deploy in this case.



 Comments   
Comment by Lukas Jungmann [ 18/Jan/13 ]

as soon as load-on-startup element is removed from web.xml, application deploys fine and web service is responding to requests, so the best and the easiest fix would be on the JDeveloper side to not generate load-on-starup element.

problem of that element is that it forces servlet container to instantiate the class before webservice logic is in place and causes classcastexception - this is more a configuration error which is tracked in original GLASSFISH-3297 therefore marking this as a duplicate of that issue.





[GLASSFISH-19127] UnmarshalException on abstract class Created: 05/Oct/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Andres Assignee: Iaroslav Savytskyi
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JAXB

 Description   

I have a problem with a webservice, that runs on glassfish 3.1.1, but fails on glassfish 3.1.2.2

@XmlSeeAlso({
	B.class,
	BId.class,
	C.class,
	CId.class
})
public abstract class A {

	private Id id;
}

public abstract class Id {

}

public class B extends A {}

public class C extends A {}

public class BId extends Id {}

public class CId extends Id {}

class B get's a BId at runtime, C a CId.

I have several other places, where I have abstract classes and the webservice serialization works just fine and I see a xsi:type qualifier in the generated xml. In this case however, no xsi:type qualifier is added and I get something like:

<a xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="B">
	<id>
	 ...
	</id>
    ...
</a>

So the unmarshalling can't identify the type of the id and tries to instantiate an abstract Id instead of a subclass.

I noticed, that glassfish since 3.1.2 uses eclipselink moxy and suspect that might be the reason why this fails now.



 Comments   
Comment by Iaroslav Savytskyi [ 18/Jan/13 ]

I've tried to reproduce the problem with a given info in JAXB 2.2.5.3 and 2.2.7 with no luck.
If the problem still exists - please provide small test case.

Comment by Thomas Andres [ 18/Jan/13 ]

Thanks for trying. I'm sorry I don't ahve a clean test case. I've meanwhile worked around the problem.





[GLASSFISH-19117] jsr109-impl module is always getting started Created: 29/Sep/12  Updated: 11/Oct/12  Resolved: 11/Oct/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b56_ms5
Fix Version/s: 4.0_b57

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: spo

 Description   

I noticed jsr109-impl module is getting activated and this is causing the whole web service stack to get resolved at startup time.
I think the reason behind this that we have config beans which have been become part of this module in svn rev #48478.

See GLASSFISH-17656 for why we should not have config beans in implementation modules.



 Comments   
Comment by Lukas Jungmann [ 11/Oct/12 ]

http://java.net/projects/glassfish/sources/svn/revision/56397
http://java.net/projects/glassfish/sources/svn/revision/56398





[GLASSFISH-19096] LazyMPMProvider does not release disposed endpoints Created: 21/Sep/12  Updated: 07/Feb/13  Resolved: 07/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b73

Type: Bug Priority: Major
Reporter: bebbo Assignee: Lukas Jungmann
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

package com.sun.xml.ws.api.server;

Memory leak after undeployment of an ear.

deploy an ear with web services and jpa
invoke at least one ws which uses jpa
deploy the same ear again

=> the first deployed ear is not properly undeployed. (VisualVM is showing two instances of EarClassLoader

It's caused by unreleased but already disposed endpoints.

my patch performs some cleanup when registering an endpoint. I bet there is a proper solution, but this works.

    public void registerEndpoint(final WSEndpointScopeChangeListener wsEndpoint) {
        endpointsWaitingForMOM.add(wsEndpoint);
        if (!isProviderInDefaultScope())
            wsEndpoint.scopeChanged(scope);

        // remove disposed end points
        for (final WSEndpointScopeChangeListener wse : new ArrayList<WSEndpointScopeChangeListener>(
                endpointsWaitingForMOM)) {
            Boolean disposed = (Boolean) getMember(wse, wse.getClass(), "disposed");
            if (Boolean.TRUE.equals(disposed)) {
                endpointsWaitingForMOM.remove(wse);
            }
        }

    }

    private static Object getMember(Object reference, Class<?> clazz, String memberName)  {
        try {
            final Field memberField = clazz.getDeclaredField(memberName);
            memberField.setAccessible(true);
            final Object object = memberField.get(reference);
            return object;
        } catch (NoSuchFieldException nsfe) {
            if (clazz.getSuperclass() == null)
                return null;
            return getMember(reference, clazz.getSuperclass(), memberName);
        } catch (Exception e) {
        }
        return null;
    }


 Comments   
Comment by shreedhar_ganapathy [ 13/Dec/12 ]

-> Deployment
-> Hong for further eval.

Comment by Hong Zhang [ 13/Dec/12 ]

Assigning to the webservices team to follow up on this to see we can apply the patch in the webservices code to properly clean up endpoints for undeployment.

Comment by Lukas Jungmann [ 07/Feb/13 ]

http://java.net/projects/glassfish/sources/svn/revision/59263





[GLASSFISH-19088] deployment fails for EJB based ws provider implementation class in web project Created: 19/Sep/12  Updated: 19/Oct/12  Resolved: 19/Oct/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.1
Fix Version/s: 4.0_b58

Type: Bug Priority: Major
Reporter: Lukas Jungmann Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive webapp1.zip    
Issue Links:
Related
is related to GLASSFISH-19089 deploying @WebServiceProvider causes ... Resolved

 Description   

-have a javaee6 web app with EJB based ws provider implementation
-deploy such webapp

=>
SEVERE: com.sun.enterprise.deployment.annotation.context.WebBundleContext cannot be cast to com.sun.enterprise.deployment.annotation.context.EjbContext
SEVERE: Exception while deploying the app [WebApplication1]
SEVERE: com.sun.enterprise.deployment.annotation.context.WebBundleContext cannot be cast to com.sun.enterprise.deployment.annotation.context.EjbContextat org.glassfish.apf.AnnotationInfo@3f4f1a07
java.lang.IllegalStateException: com.sun.enterprise.deployment.annotation.context.WebBundleContext cannot be cast to com.sun.enterprise.deployment.annotation.context.EjbContextat org.glassfish.apf.AnnotationInfo@3f4f1a07
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:505)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:447)
...
Caused by: java.lang.ClassCastException: com.sun.enterprise.deployment.annotation.context.WebBundleContext cannot be cast to com.sun.enterprise.deployment.annotation.context.EjbContext
at org.glassfish.webservices.connector.annotation.handlers.WebServiceProviderHandler.processAnnotation(WebServiceProviderHandler.java:143)
at com.sun.enterprise.deployment.annotation.factory.SJSASFactory$1.processAnnotation(SJSASFactory.java:113)
...

see also: http://stackoverflow.com/questions/8017549/glassfish-classcastexception-webbundlecontext-and-ejbcontext



 Comments   
Comment by Lukas Jungmann [ 19/Sep/12 ]

sample app

Comment by Lukas Jungmann [ 19/Oct/12 ]

http://java.net/projects/glassfish/sources/svn/revision/56521
http://java.net/projects/glassfish/sources/svn/revision/56522





[GLASSFISH-19063] Web-service client deployment fails with NullPointerException in WSATGatewayRM.setTxLogDirs(WSATGatewayRM.java:430) Created: 07/Sep/12  Updated: 16/Oct/12  Resolved: 16/Oct/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Marcin_C Assignee: arjavdesai
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2.2


Attachments: Text File server.log    

 Description   

I have the following situation
Webservice client (Glassfish 3.1.2.2) ----> Webservice server (up & running)

During the deployment phase I am getting exception as indicated in the attached file.
I want to underline that the same application (the deployment) is working fine with Glassfish 3.1.1

The exception is

java.lang.RuntimeException: EJB Container initialization error
	at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:242)
...
Caused by: java.lang.NullPointerException
	at java.io.File.<init>(File.java:222)
	at com.sun.xml.ws.tx.at.internal.WSATGatewayRM.setTxLogDirs(WSATGatewayRM.java:430)


 Comments   
Comment by Hong Zhang [ 07/Sep/12 ]

As the stack trace is from webservices code, I will let the webservices team do the evaluation on this one.

Comment by xavierandre [ 10/Oct/12 ]

Hi,

I have same issue on same GF version, any idea of time for fix ?
Thank you.

Comment by arjavdesai [ 12/Oct/12 ]

Is this application a WS-AT client or service? Can you please post the application as well?

If its a client, you need to apply the work-around as specified in release notes and part of http://java.net/jira/browse/WSIT-1500 i.e.

"The WS-C and WS-AT endpoints necessary for WS-AT are deployed when the first web service is deployed. Therefore, it is necessary to have at least one web service deployed for WS-AT to function properly even in the case where only clients are used in the Metro instance."

Comment by Marcin_C [ 15/Oct/12 ]

This is a client application. Unfortunately I cannot attach any source codes.

Comment by arjavdesai [ 16/Oct/12 ]

As I mentioned in my first comment, if you have just a client application, you need to deploy a simple/any service application first as mentioned in the release notes.





[GLASSFISH-19055] Invalid Chunk header while running web services on Glassfish 3.1.2 Created: 05/Sep/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b23
Fix Version/s: 4.0_b72_EE7MS4

Type: Bug Priority: Major
Reporter: talk2umakanth Assignee: Lukas Jungmann
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 5.4 / glassfish 3.1.2 / jdk1.6_11



 Description   

Receiving invalid chunk header

[#|2012-08-22T17:03:54.717-0400|SEVERE|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|org.apache.axis2.AxisFault: Invalid chunk header
at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:512)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:370)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:416)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at eTrace.webservice.userServices.GUIDGeneratorWSStub.generateGUID2013(GUIDGeneratorWSStub.java:461)
at org.apache.jsp.sam.testGuidHEB_jsp._jspService(testGuidHEB_jsp.java from :137)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.reflexis.filters.RfxSecurityFilter.doFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by talk2umakanth [ 05/Sep/12 ]

I think we figured out the cause of the problem.

Test Case 1

  • We have the WSDL for a webservice and if we call the SOAP endopoint through the webserver and hit a webserver port like 80, Invalid Chunk header is thrown

The below does not work
http://192.168.1.171:80/RTMHEBSB/services/GUIDGeneratorWS.GUIDGeneratorWSHttpSoap12Endpoint

Test Case 2

Comment by Lukas Jungmann [ 18/Jan/13 ]

I don't see how this is related to GlassFish. Stacktrace clearly states that the problem lies somewhere in Axis or user implemented class. Feel free to reopen together with more info if you think otherwise. Thank you.





[GLASSFISH-19038] 'wget' on stateless webservice bean leaks memory Created: 27/Aug/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1_b43, 3.1.2
Fix Version/s: 4.0

Type: Bug Priority: Critical
Reporter: bhicks01 Assignee: Martin Grebac
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

redhat 5.4 x86_64, glassfish 3.1+



 Description   

When running a Stateless Webservice EJB, the glassfish domain will leak memory when the WSDL is accessed. The culprit appears to be the "com.sun.ejb.EjbInvocation" object, which does not get garbage collected. It appears that about 183 bytes are being leaked upon each invocation. After some time, this causes the domain to stop functioning due to OutOfMemory exceptions. Regardless of the heap size, this will occur.

I used 'jvisualvm' to monitor the memory and object allocations, and during profiling the EjbInvocation generations grew continuously. This can also be observed by doing the memory sampling, as well, and filtering for 'EjbInvocation'.

To test this, I deployed a simple web service, then ran a script to get the wsdl:
'wget http://host:port/TestService/TestService?WSDL'

With my domain configuration (default), to 512MB heap space, it died after ~2.5 million 'wget's.



 Comments   
Comment by Martin Grebac [ 18/Jan/13 ]

Fixed in trunk.
Committed revision 58651.
Revision: 58651
Author : snajper
Date : Jan 18, 2013 3:51:44 PM
Fix of GF19038 - wget' on stateless webservice bean leaks memory





[GLASSFISH-19032] Invalid Chunk header while running web services on Glassfish 3.1.2 Created: 22/Aug/12  Updated: 05/Sep/12  Resolved: 23/Aug/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Major
Reporter: talk2umakanth Assignee: Lukas Jungmann
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 5.4 / glassfish 3.1.2 / jdk1.6_11



 Description   

Receiving invalid chunk header

[#|2012-08-22T17:03:54.717-0400|SEVERE|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|org.apache.axis2.AxisFault: Invalid chunk header
at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:512)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:370)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:416)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at eTrace.webservice.userServices.GUIDGeneratorWSStub.generateGUID2013(GUIDGeneratorWSStub.java:461)
at org.apache.jsp.sam.testGuidHEB_jsp._jspService(testGuidHEB_jsp.java from :137)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.reflexis.filters.RfxSecurityFilter.doFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by Lukas Jungmann [ 22/Aug/12 ]

Hi, can you provide (attach to this issue) some simple application for reproducing this issue? Without that it is hard to say what's wrong and where. Also can you try to reproduce the issue with latest GlassFish 3.1.2.2 (available from http://glassfish.java.net/downloads/3.1.2.2-final.html)?

Thanks.

Comment by talk2umakanth [ 23/Aug/12 ]

Our build is deployed on Glass fish 3.1.2.2 (build 5). We updated it yesterday

Comment by Lukas Jungmann [ 23/Aug/12 ]

ok. But still I don't know how can I help you without more info (I need to get at least one line from a stacktrace starting either with com.sun.xml.ws or org.glassfish.webservices prefix - it may not be enough but it's worth trying) or reproducible testcase. I even cannot see anything related to Metro/JAX-WS RI in the stacktrace. Top lines in a stacktrace are comming from Axis, so I'd try to get help there first... http://axis.apache.org/axis/bugs.html

Comment by Lukas Jungmann [ 23/Aug/12 ]

incomplete for now

Comment by talk2umakanth [ 05/Sep/12 ]

I think we figured out the cause of the problem.

Test Case 1

  • We have the WSDL for a webservice and if we call the SOAP endopoint through the webserver and hit a webserver port like 80, Invalid Chunk header is thrown

The below does not work
http://192.168.1.171:80/RTMHEBSB/services/GUIDGeneratorWS.GUIDGeneratorWSHttpSoap12Endpoint

Test Case 2





[GLASSFISH-19010] 33 jaxws regressions in reverse mode on WINDOWS platform only with GFV4.0 (build 49) Created: 16/Aug/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b49
Fix Version/s: None

Type: Bug Priority: Major
Reporter: teelucksingh Assignee: Lukas Jungmann
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WINDOWS


Attachments: Text File run.log     Text File server.log    

 Description   

We are getting 33 jaxws failures from the following jaxws test in appclient container only on WINDOWS. The failures seem to be related to grizzly code. I will attach the run.log and the server.log as attachments. To reproduce failures you can contact me :

Here are the tests failures:
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#ClientPassNullTest_from_wsappclient_reverse: Client_C
lientPassNullTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#EndpointPassNullTest_from_wsappclient_reverse: Client
_EndpointPassNullTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallAnnotationTypeTest_from_wsappclient_reverse:
Client_MarshallAnnotationTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallAnonymousTypeTest_from_wsappclient_reverse: C
lient_MarshallAnonymousTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallAnySimpleTypeTest_from_wsappclient_reverse: C
lient_MarshallAnySimpleTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallAnyURITypeTest_from_wsappclient_reverse: Clie
nt_MarshallAnyURITypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallBigIntegerTypesTest_from_wsappclient_reverse:
Client_MarshallBigIntegerTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallComplexTypesTest_from_wsappclient_reverse: Cl
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallDurationTest_from_wsappclient_reverse: Client
_MarshallDurationTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallEnumTypesTest_from_wsappclient_reverse: Clien
t_MarshallEnumTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallIDTypeTest_from_wsappclient_reverse: Client_M
arshallIDTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallIncludedStringTypeTest_from_wsappclient_rever
se: Client_MarshallIncludedStringTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallIntegerRangeTypeTest_from_wsappclient_reverse
: Client_MarshallIntegerRangeTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallJavaArrayTest_from_wsappclient_reverse: Clien
t_MarshallJavaArrayTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallJavaBeanTest_from_wsappclient_reverse: Client
_MarshallJavaBeanTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallLanguageTypeTest_from_wsappclient_reverse: Cl
ient_MarshallLanguageTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallListTypesTest_from_wsappclient_reverse: Clien
t_MarshallListTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallLiteralFaultsTest_from_wsappclient_reverse: C
lient_MarshallLiteralFaultsTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallMapSimpleTypesTest_from_wsappclient_reverse:
Client_MarshallMapSimpleTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallNCNameTypeTest_from_wsappclient_reverse: Clie
nt_MarshallNCNameTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallNameTypeTest_from_wsappclient_reverse: Client
_MarshallNameTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallNormalizedStringTypeTest_from_wsappclient_rev
erse: Client_MarshallNormalizedStringTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallOneWayTest_from_wsappclient_reverse: Client_M
arshallOneWayTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallOtherSimpleTypesTest_from_wsappclient_reverse
: Client_MarshallOtherSimpleTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallPrimitiveTest_from_wsappclient_reverse: Clien
t_MarshallPrimitiveTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallStandardJavaClassesTest_from_wsappclient_reve
rse: Client_MarshallStandardJavaClassesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallStructXMLSchemaTypesTest_from_wsappclient_rev
erse: Client_MarshallStructXMLSchemaTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallTokenTypeTest_from_wsappclient_reverse: Clien
t_MarshallTokenTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallUnsignedTypesTest_from_wsappclient_reverse: C
lient_MarshallUnsignedTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallVariousSchemaTypesListTypeTest_from_wsappclie
nt_reverse: Client_MarshallVariousSchemaTypesListTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallVariousSchemaTypesTest_from_wsappclient_rever
se: Client_MarshallVariousSchemaTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallVoidTest_from_wsappclient_reverse: Client_Mar
shallVoidTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#ClientPassNullTest_from_wsappclient_reverse: Client_C
lientPassNullTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#EndpointPassNullTest_from_wsappclient_reverse: Client
_EndpointPassNullTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallAnnotationTypeTest_from_wsappclient_reverse:
Client_MarshallAnnotationTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallAnonymousTypeTest_from_wsappclient_reverse: C
lient_MarshallAnonymousTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallAnySimpleTypeTest_from_wsappclient_reverse: C
lient_MarshallAnySimpleTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallAnyURITypeTest_from_wsappclient_reverse: Clie
nt_MarshallAnyURITypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallBigIntegerTypesTest_from_wsappclient_reverse:
Client_MarshallBigIntegerTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallComplexTypesTest_from_wsappclient_reverse: Cl
ient_MarshallComplexTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallDateTimeTest_from_wsappclient_reverse: Client
_MarshallDateTimeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallDurationTest_from_wsappclient_reverse: Client
_MarshallDurationTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallEnumTypesTest_from_wsappclient_reverse: Clien
t_MarshallEnumTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallIDTypeTest_from_wsappclient_reverse: Client_M
arshallIDTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallIncludedStringTypeTest_from_wsappclient_rever
_MarshallDateTimeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallDurationTest_from_wsappclient_reverse: Client
_MarshallDurationTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallEnumTypesTest_from_wsappclient_reverse: Clien
t_MarshallEnumTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallIDTypeTest_from_wsappclient_reverse: Client_M
arshallIDTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallIncludedStringTypeTest_from_wsappclient_rever
se: Client_MarshallIncludedStringTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallIntegerRangeTypeTest_from_wsappclient_reverse
: Client_MarshallIntegerRangeTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallJavaArrayTest_from_wsappclient_reverse: Clien
t_MarshallJavaArrayTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallJavaBeanTest_from_wsappclient_reverse: Client
_MarshallJavaBeanTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallLanguageTypeTest_from_wsappclient_reverse: Cl
ient_MarshallLanguageTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallListTypesTest_from_wsappclient_reverse: Clien
t_MarshallListTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallLiteralFaultsTest_from_wsappclient_reverse: C
lient_MarshallLiteralFaultsTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallMapSimpleTypesTest_from_wsappclient_reverse:
Client_MarshallMapSimpleTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallNCNameTypeTest_from_wsappclient_reverse: Clie
nt_MarshallNCNameTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallNameTypeTest_from_wsappclient_reverse: Client
_MarshallNameTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallNormalizedStringTypeTest_from_wsappclient_rev
erse: Client_MarshallNormalizedStringTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallOneWayTest_from_wsappclient_reverse: Client_M
arshallOneWayTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallOtherSimpleTypesTest_from_wsappclient_reverse
: Client_MarshallOtherSimpleTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallPrimitiveTest_from_wsappclient_reverse: Clien
t_MarshallPrimitiveTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallStandardJavaClassesTest_from_wsappclient_reve
rse: Client_MarshallStandardJavaClassesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallStructXMLSchemaTypesTest_from_wsappclient_rev
erse: Client_MarshallStructXMLSchemaTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallTokenTypeTest_from_wsappclient_reverse: Clien
t_MarshallTokenTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallUnsignedTypesTest_from_wsappclient_reverse: C
lient_MarshallUnsignedTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallVariousSchemaTypesListTypeTest_from_wsappclie
nt_reverse: Client_MarshallVariousSchemaTypesListTypeTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallVariousSchemaTypesTest_from_wsappclient_rever
se: Client_MarshallVariousSchemaTypesTest_from_wsappclient_reverse
com/sun/ts/tests/jaxws/ee/w2j/rpc/literal/marshalltest/Client.java#MarshallVoidTest_from_wsappclient_reverse: Client_Mar
shallVoidTest_from_wsappclient_reverse



 Comments   
Comment by Martin Grebac [ 12/Dec/12 ]

Hi, is this issue still valid? Are the failures still present in recent builds?

Comment by Lukas Jungmann [ 18/Jan/13 ]

Hi,

is this issue still valid in the latest trunk, please?

Thanks.

Comment by Lukas Jungmann [ 18/Jan/13 ]

also marking incomplete for now





[GLASSFISH-18997] Message IDs are missing for the messages in webservices-osgi.jar Created: 13/Aug/12  Updated: 15/Jan/13  Resolved: 15/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b45
Fix Version/s: 4.0_b72_EE7MS4

Type: Bug Priority: Major
Reporter: tak09 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Message IDs are missing for the messages in webservices-osgi.jar
Extract glassfish3/glassfish/modules/webservices-osgi.jar
Open each .properties file and check the message. Several messages don't have ID. For example,

runtime.modeler.oneway.operation.no.checked.exceptions=Oneway operation should not throw any checked exceptions class:

{0} method: {1} throws: {2}
runtime.modeler.invalid.soapbinding.parameterstyle= Incorrect usage of Annotation {0}

on

{1}

, ParameterStyle can only be WRAPPED with RPC Style Web service.

Please check other messages as well, because these are just examples. In fact, many other messages in this jar file don't have ID.



 Comments   
Comment by Lukas Jungmann [ 13/Aug/12 ]

Assigning to myself.

Do all messages coming from 'external' library have to have IDs? Is there some guideline for this? How the ID should look like - is ie METROXXXX good enough?

Comment by tak09 [ 14/Aug/12 ]

Please refer to this guideline.
https://wikis.oracle.com/display/GlassFish/GlassFishV3LoggingMessageFormat
"For v3 the requirement applies to SEVERE and WARNING messages only. In later versions of v3 message ids are required for INFO level messages too." Thank you.

Comment by Lukas Jungmann [ 15/Jan/13 ]

as of r58443 all messages should have ID





[GLASSFISH-18976] Missing packages in recently introduced jaxb modules Created: 05/Aug/12  Updated: 07/Aug/12  Resolved: 06/Aug/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b45
Fix Version/s: 4.0_b46

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File new-packages-list.txt     Text File old-packages-list.txt    

 Description   

This is caused by recent JAXB integration in GlassFish. The new jaxb modules don't have some of the packages that old jaxb modules used to export. For you information, I confirm that I have considers jaxb-extra-osgi.jar as well. The difference between the sets of packages exported by old and new jaxb modules are given below (0.s refers to old packages and 1.s refers to new packages):
Both old-packages-list.txt and new-packages-list.txt are attached as well.

ss141213@Sahoo:/tmp/g$ diff old-packages-list.txt new-packages-list.txt
8a9,10
> com.sun.msv.datatype
> com.sun.msv.datatype.regexp
10,17c12,13
< com.sun.msv.grammar
< com.sun.msv.grammar.trex
< com.sun.msv.reader
< com.sun.msv.reader.trex.ng
< com.sun.msv.reader.util
< com.sun.msv.util
< com.sun.msv.verifier
< com.sun.msv.verifier.regexp

> com.sun.msv.datatype.xsd.datetime
> com.sun.msv.datatype.xsd.ngimpl
101a98
> com.sun.xml.util

As you can see there are some new packages, but some are missing too. e.g. com.sun.msv.grammar is missing.



 Comments   
Comment by Lukas Jungmann [ 05/Aug/12 ]

Martin, is this expected state?

thx.

Comment by Martin Grebac [ 05/Aug/12 ]

Don't know, we have to check one by one - please work with Yarda on this. Thanks.

Comment by Sanjeeb Sahoo [ 06/Aug/12 ]

Some of the missing packages are actually needed by some bundles. One can find out more about how bundles depend on various packages by following instructions in [1].

Because of this issue, I am seeing the following failure when I try to start GlassFish to load bundles in ondemand mode. To start server in ondemand mode, just set glassfish.osgi.ondemand=true. It's set to false by default. I am also seeing some issues on Equinox platform, but they seem to be caused by this jaxb issue and recent jersey upgrade.

6 Aug, 2012 6:34:20 AM ObrHandler findResource
INFO: Using the first one from the list of 1 discovered bundles shown below: [com.ctc.wstx/0.0.0]
6 Aug, 2012 6:34:20 AM ObrHandler resolve
INFO: At the end of first pass, resolver outcome is
: Added resources: [
com.ctc.wstx, 0.0.0, file:/space/ss141213/WS/gf/trunk-svn/all/main/appserver/distributions/glassfish/target/stage/glassfish3/glassfish/modules/woodstox-osgi.jar]
Required Resources: []
Optional resources (deployed): []
Unsatisfied requirements: [
package&(package=com.sun.msv.grammar.trex))
package&(package=com.sun.msv.util))
package&(package=com.sun.msv.verifier.regexp))
package&(package=com.sun.msv.reader.trex.ng))
package&(package=com.sun.msv.verifier))
package&(package=com.sun.msv.reader.util))
package&(package=com.sun.msv.grammar))
package&(package=com.sun.msv.reader))]
6 Aug, 2012 6:34:20 AM ObrHandler deploy
WARNING: Unable to satisfy the requirements: [org.apache.felix.bundlerepository.impl.ReasonImpl@2cb491, org.apache.felix.bundlerepository.impl.ReasonImpl@199ffdd, org.apache.felix.bundlerepository.impl.ReasonImpl@1868b72, org.apache.felix.bundlerepository.impl.ReasonImpl@17cdd50, org.apache.felix.bundlerepository.impl.ReasonImpl@16d383a, org.apache.felix.bundlerepository.impl.ReasonImpl@a5b721, org.apache.felix.bundlerepository.impl.ReasonImpl@f96845, org.apache.felix.bundlerepository.impl.ReasonImpl@102d72d]
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.jvnet.hk2.component.ComponentException: Failed to create a habitat
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateServiceLocator(AbstractModulesRegistryImpl.java:182)
at com.sun.enterprise.module.bootstrap.Main.createServiceLocator(Main.java:284)
at org.jvnet.hk2.osgiadapter.HK2Main.createServiceLocator(HK2Main.java:119)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:98)
at com.sun.enterprise.glassfish.bootstrap.GlassFishRuntimeDecorator.newGlassFish(GlassFishRuntimeDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.newGlassFish(OSGiGlassFishRuntime.java:93)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
... 6 more
Caused by: java.lang.RuntimeException: Unable to install module [ OSGiObrModuleImpl::Name: [com.ctc.wstx], State: [NEW]] due to unsatisfied dependencies. See previous log messages.
at org.jvnet.hk2.osgiadapter.OSGiObrModuleImpl.init(OSGiObrModuleImpl.java:86)
at org.jvnet.hk2.osgiadapter.OSGiObrModuleImpl.parseInhabitants(OSGiObrModuleImpl.java:171)
at org.jvnet.hk2.osgiadapter.AbstractOSGiModulesRegistryImpl.parseInhabitants(AbstractOSGiModulesRegistryImpl.java:102)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateServiceLocator(AbstractModulesRegistryImpl.java:178)
... 12 more

[1] https://wikis.oracle.com/display/GlassFish/OsgiPkgDepAnalyser

Comment by Lukas Jungmann [ 06/Aug/12 ]

fixed http://java.net/projects/glassfish/sources/svn/revision/55318

verify, please.

Thanks.

Comment by Sanjeeb Sahoo [ 07/Aug/12 ]

verified the fix. thanks.





[GLASSFISH-18959] Seeing 27 CTS regressions in JAXWS tree with GF V4.0 Nightly Builds starting July 25, 2012 Created: 30/Jul/12  Updated: 08/Nov/12  Resolved: 08/Nov/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b48
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: alanf760 Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: Text File run.log     Text File server.log    

 Description   

We are seeing 27 CTS regressions in JAXWS tree with GF V4.0 Nightly Builds starting July 25, 2012.

After Lukas Jungman investigating he believes the failures are a result of this fix: this seems to be related to the fix for http://java.net/jira/browse/WSIT-1637

Below are the failures and exception. I am attaching the run log and server log.

[javatest.batch] 07-27-2012 11:55:57: ERROR: com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server:
com.sun.xml.ws.metro.api.config.management.ManagedEndpoint cannot be cast to com.sun.xml.ws.server.WSEndpointImpl Please see the se
rver log to find more detail regarding exact cause of the failure.
[javatest.batch] at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:193)
[javatest.batch] at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:126)
[javatest.batch] at com.sun.xml.ws.client.sei.StubHandler.readResponse(StubHandler.java:252)
[javatest.batch] at com.sun.xml.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:181)
[javatest.batch] at com.sun.xml.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:262)
[javatest.batch] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:128)
[javatest.batch] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:102)
[javatest.batch] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:154)
[javatest.batch] at $Proxy55.getEndpointReference2Test(Unknown Source)
[javatest.batch] at com.sun.ts.tests.jaxws.api.javax_xml_ws.WebServiceContext.Client.getEndpointReference2Test(Client.java:25
6)
[javatest.batch] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[javatest.batch] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[javatest.batch] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[javatest.batch] at java.lang.reflect.Method.invoke(Method.java:601)
[javatest.batch] at com.sun.ts.lib.harness.EETest.run(EETest.java:495)
[javatest.batch] at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
[javatest.batch] at com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:30)
[javatest.batch] at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:102)
[javatest.batch] at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:392)
[javatest.batch] at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:210)
[javatest.batch] at com.sun.ts.lib.harness.EETest.run(EETest.java:204)
[javatest.batch] at com.sun.ts.tests.common.vehicle.wsappclient.WSAppclient.main(WSAppclient.java:39)
[javatest.batch] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[javatest.batch] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[javatest.batch] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[javatest.batch] at java.lang.reflect.Method.invoke(Method.java:601)
[javatest.batch] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:439)
[javatest.batch] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:183)
[javatest.batch] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[javatest.batch]
[javatest.batch] 07-27-2012 11:55:57: ERROR: Exception at:
[javatest.batch] 07-27-2012 11:55:57: ERROR: com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server:
com.sun.xml.ws.metro.api.config.management.ManagedEndpoint cannot be cast to com.sun.xml.ws.server.WSEndpointImpl Please see the se
rver log to find more detail regarding exact cause of the failure.
[javatest.batch] at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:193)
[javatest.batch] at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:126)
[javatest.batch] at com.sun.xml.ws.client.sei.StubHandler.readResponse(StubHandler.java:252)
[javatest.batch] at com.sun.xml.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:181)
[javatest.batch] at com.sun.xml.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:262)
[javatest.batch] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:128)
[javatest.batch] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:102)
[javatest.batch] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:154)
[javatest.batch] at $Proxy55.getEndpointReference2Test(Unknown Source)
[javatest.batch] at com.sun.ts.tests.jaxws.api.javax_xml_ws.WebServiceContext.Client.getEndpointReference2Test(Client.java:25
6)
[javatest.batch] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[javatest.batch] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[javatest.batch] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[javatest.batch] at java.lang.reflect.Method.invoke(Method.java:601)
[javatest.batch] at com.sun.ts.lib.harness.EETest.run(EETest.java:495)
[javatest.batch] at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
[javatest.batch] at com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:30)
[javatest.batch] at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:102)
[javatest.batch] at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:392)
[javatest.batch] at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:210)
[javatest.batch] at com.sun.ts.lib.harness.EETest.run(EETest.java:204)
[javatest.batch] at com.sun.ts.tests.common.vehicle.wsappclient.WSAppclient.main(WSAppclient.java:39)
[javatest.batch] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[javatest.batch] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[javatest.batch] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[javatest.batch] at java.lang.reflect.Method.invoke(Method.java:601)
[javatest.batch] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:439)
[javatest.batch] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:183)
[javatest.batch] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[javatest.batch]
[javatest.batch] 07-27-2012 11:55:57: cleanup ok

[javatest.batch] FAILED........com/sun/ts/tests/jaxws/api/javax_xml_ws/WebServiceContext/Client.java#getEndpointReferenc
e2Test_from_
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/api/javax_xml_ws/WebServiceContext/Client.java#getEndpointReferenc
e2Test_from_
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/api/javax_xml_ws/WebServiceContext/Client.java#getEndpointReferenc
e2Test_from_
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/api/javax_xml_ws/WebServiceContext/Client.java#getEndpointReferenc
eTest_from_w
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/api/javax_xml_ws/WebServiceContext/Client.java#getEndpointReferenc
eTest_from_w
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/api/javax_xml_ws/WebServiceContext/Client.java#getEndpointReferenc
eTest_from_w
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetEPRViaWSCTest1_from
_wsappclient
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetEPRViaWSCTest1_from
_wsejb
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetEPRViaWSCTest1_from
_wsservlet
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetEPRViaWSCTest2_from
_wsappclient
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetEPRViaWSCTest2_from
_wsejb
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetEPRViaWSCTest2_from
_wsservlet
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetPortViaWSCAndWSFTru
eTest_from_w
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetPortViaWSCAndWSFTru
eTest_from_w
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRGetPortViaWSCAndWSFTru
eTest_from_w
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateDispatchWS
FTrueAndInvo
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateDispatchWS
FTrueAndInvo
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateDispatchWS
FTrueAndInvo
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateDispatchWS
FTrueAndInvo
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateDispatchWS
FTrueAndInvo
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateDispatchWS
FTrueAndInvo
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateJAXBDispat
chWSFTrueAnd
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateJAXBDispat
chWSFTrueAnd
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#EPRViaWSCCreateJAXBDispat
chWSFTrueAnd
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#ServiceGetPortViaWSCAndWS
FTrueTest_fr
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#ServiceGetPortViaWSCAndWS
FTrueTest_fr
[javatest.batch] FAILED........com/sun/ts/tests/jaxws/wsa/j2w/document/literal/epr/Client.java#ServiceGetPortViaWSCAndWS
FTrueTest_fr



 Comments   
Comment by Martin Grebac [ 10/Aug/12 ]

Fixed in latest metro - should be fixed in GF with next metro integration.





[GLASSFISH-18807] Whitespace in web service handler chain files should be trimmed Created: 15/Jun/12  Updated: 16/Jun/12  Resolved: 15/Jun/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b39

Type: Bug Priority: Major
Reporter: bland999 Assignee: Lukas Jungmann
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Issue Links:
Related
is related to GLASSFISH-18598 Glassfish 3.1.2 can't find JAX-WS han... Resolved
Tags: handlerchain, webservice

 Description   

When web services are deployed with handler chains, they may refer in the handler chain file to a particular class which implements the handler, as follows:

<javaee:handler-class>myHandler</javaee:handler-class>

Glassfish 3.1.2, 3.1.1, and 3.1 all fail to trim any white space that might be before and after that name. This results in the following...

<javaee:handler-class>myHandler </javaee:handler-class>

...leading to a runtime exception:

[#|2012-04-03T21:59:11.769-0400|SEVERE|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=16;_ThreadName=Thread-3;|Unable to load handler class myHandler

java.lang.ClassNotFoundException: myHandler

In fact, there is whitespace at the end of the name that is being printed in the logs...

For more information, see:

https://forums.oracle.com/forums/thread.jspa?threadID=2369079&tstart=0

Thanks.



 Comments   
Comment by Martin Grebac [ 15/Jun/12 ]

Lukasi, am I right you already mentioned this issue some time ago?

Comment by Lukas Jungmann [ 15/Jun/12 ]

content of handler-class element must be a string without leading/trailing space(s), as per javaee:string definition in http://java.sun.com/xml/ns/javaee/javaee_5.xsd, and as such it is treated and correctly reports that class "myHandler " is not found

Comment by bland999 [ 16/Jun/12 ]

The cited schema states with respect to javaee:string the following:

"This is a special string datatype that is defined by Java EE as
a base type for defining collapsed strings. When schemas
require trailing/leading space elimination as well as
collapsing the existing whitespace, this base type may be
used."

Those two sentences clarify what the end result should be, but I wonder if it is so clear about WHO should be responsible for that end result. I have seen multiple people independently complaining about this type of error within the Glassfish code going back 5 years. It seems to me that if the code can be enhanced to at least strip away leading and trailing whitespace, that would still be advantageous.

If you don't agree, then AT MINIMUM, it would be greatly useful to simply add QUOTES to the error message that reports the error as follows:

Unable to load handler class "myHandler " <<<<--- clearly show the extra spaces here.

There are other places where Class.forName is being called where the same potentially confusing message is being printed.

Keep in mind that most JAX-WS developers do not know when a javaee:string is being used versus an xsd:string. I thoroughly agree that at the end of the day, the developer is responsible, but with a little bit of helpful code, Glassfish could be so much more clearer in this case.

Thanks for listening. I've been using Glassfish for more than 5 years now, and it is my application server of choice, no question about that. Great job, Glassfish team!

Comment by bland999 [ 16/Jun/12 ]

By the way, in a similar issue from "way back when", it was implied that this type of trimming on a "previous version of Glassfish" used to work...

See http://java.net/jira/browse/GLASSFISH-8615





[GLASSFISH-18801] Web Services tester fails accessibility requirements Created: 12/Jun/12  Updated: 27/Jul/12  Resolved: 27/Jul/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b23
Fix Version/s: 4.0_b48

Type: Bug Priority: Major
Reporter: Kim Haase Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: metro2_2_1-waived

 Description   

When you open the Web Service Tester at, for example, http://localhost:8080/HelloServiceBeanService/HelloServiceBean?Tester (for the HelloServiceBean application in the Java EE 6 Tutorial, http://docs.oracle.com/javaee/6/tutorial/doc/bnbor.html#bnbox), you get an HTML page whose source looks like this:

<HTML><HEAD><TITLE>HelloServiceBeanService Web Service Tester</TITLE></HEAD><BODY><H1>HelloServiceBeanService Web Service Tester</H1><br>This form will allow you to test your web service implementation (<A HREF="http://stella:8080/HelloServiceBeanService/HelloServiceBean?WSDL">WSDL File</A>)<hr>To invoke an operation, fill the method parameter(s) input boxes and click on the button labeled with the method name.<H3>Methods :</H3><FORM METHOD="POST">public abstract java.lang.String com.sun.tutorial.javaee.ejb.helloservice.HelloServiceBean.sayHello(java.lang.String)<BR><INPUT TYPE=SUBMIT NAME=action value=sayHello> (<INPUT TYPE=TEXT NAME=PARAMsayHello0>)<BR><HR></FORM></BODY></HTML><FORM METHOD="POST">public abstract void com.sun.tutorial.javaee.ejb.helloservice.HelloServiceBean.helloServiceBean()<BR><INPUT TYPE=SUBMIT NAME=action value=helloServiceBean> ()<BR><HR></FORM></BODY></HTML>

In order to make this page accessible, only a few changes are needed:

1) Change <HTML> to <HTML LANG="en">. The LANG attribute is required for each HTML page. If the page varies depending on the locale, the correct locale should be used.

2) Each of the three <INPUT> tags requires a label, which is normally provided by the TITLE attribute. So the changed tags would look something like this, where sayHello is the method name.

<INPUT TYPE=SUBMIT NAME=action title="sayHello" value=sayHello>

<INPUT TYPE=TEXT NAME=PARAMsayHello0 title="sayHello parameter">

<INPUT TYPE=SUBMIT NAME=action title="helloServiceBean" value=helloServiceBean>

The requirement comes from http://www.access-board.gov/sec508/guide/1194.22.htm#%28n%29.



 Comments   
Comment by Lukas Jungmann [ 27/Jul/12 ]

http://java.net/projects/glassfish/sources/svn/revision/55235





[GLASSFISH-18787] Classloader leak in com.sun.xml.ws.server.WSEndpointImpl Created: 06/Jun/12  Updated: 26/Jul/12  Resolved: 26/Jul/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b48

Type: Bug Priority: Major
Reporter: syvalta Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Tags: metro2_2_1-waived

 Description   

After undeploying a web app which uses JAX-WS web services LazyMOMProvider still references the WS implementation class. This causes all the classes loaded by the web app classloader to be referenced until the app server restart.

jhat dump:
--> class com.sun.xml.ws.api.server.LazyMOMProvider (160 bytes) (static field INSTANCE
--> com.sun.xml.ws.api.server.LazyMOMProvider@0xe0821148 (52 bytes) (field endpointsWaitingForMOM
--> java.util.HashSet@0xe082b0e8 (24 bytes) (field map
--> java.util.HashMap@0xe08323f0 (64 bytes) (field table
--> [Ljava.util.HashMap$Entry;@0xe66afe18 (528 bytes) (Element 16 of [Ljava.util.HashMap$Entry;@0xe66afe18
--> java.util.HashMap$Entry@0xe87f13b8 (44 bytes) (field key
--> com.sun.xml.ws.server.WSEndpointImpl@0xe87f1c48 (194 bytes) (field implementationClass
--> class com.test.TestWebServiceImpl (160 bytes) (??
--> org.glassfish.web.loader.WebappClassLoader@0xe82706a8 (324 bytes)

It seems that this if clause in WSEndpoinImpl.closeManagedObjectManager evaluates to true and thus prevents the unregistration:

// ManagedObjectManager doesn't need to be closed because it exists only as a proxy
if (managedObjectManager instanceof WSEndpointMOMProxy
&& !((WSEndpointMOMProxy)managedObjectManager).isInitialized())

{ close = false; }

 Comments   
Comment by syvalta [ 06/Jun/12 ]

The instance is always registered during creation in the constructor, so it should be unconditionally unregistered in the dispose. I guess the fix would be to move LazyMOMProvider.INSTANCE.unregisterEndpoint(this) out of the if blocks so that it is always executed.

Comment by Lukas Jungmann [ 19/Jun/12 ]

fixed in jaxws-ri workspace[1], will get to GF in the next integration

[1]: http://java.net/projects/jax-ws/sources/sources/revision/13203

Comment by Lukas Jungmann [ 26/Jul/12 ]

integrated in svn r.55202





[GLASSFISH-18780] java.lang.NoClassDefFoundError: com/sun/msv/datatype/xsd/UnsignedShortType Created: 04/Jun/12  Updated: 26/Jul/12  Resolved: 26/Jul/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b39
Fix Version/s: 4.0_b48

Type: Bug Priority: Minor
Reporter: adf59 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following stack trace error is occurring on a CTS jaxrpc test causing a test regression.

Last week (B38) the class was bundled in jaxb-osgi.jar. This week (B39) it is missing.

Here is the stack trace:

[#|2012-06-01T13:59:10.017-0400|SEVERE|44.0|javax.enterprise.resource.webservices.rpc.server.http|_ThreadID=117;_ThreadName=Thread-2;|caught throwable
java.lang.NoClassDefFoundError: com/sun/msv/datatype/xsd/UnsignedShortType
at com.sun.xml.rpc.encoding.simpletype.XSDUnsignedShortEncoder.stringToObject(XSDUnsignedShortEncoder.java:63)
at com.sun.xml.rpc.encoding.literal.LiteralSimpleTypeSerializer.deserialize(LiteralSimpleTypeSerializer.java:168)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.FooVariousSchemaTypes_LiteralSerializer.doDeserialize(FooVariousSchemaTypes_LiteralSerializer.java:70)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalDeserialize(LiteralObjectSerializerBase.java:233)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.deserialize(LiteralObjectSerializerBase.java:141)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.FooVariousSchemaTypesListType_LiteralSerializer.doDeserialize(FooVariousSchemaTypesListType_LiteralSerializer.java:53)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalDeserialize(LiteralObjectSerializerBase.java:233)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.deserialize(LiteralObjectSerializerBase.java:141)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.NewSchemaTest_echoVariousSchemaTypesListTypeTest_RequestStruct_LiteralSerializer.doDeserialize(NewSchemaTest_echoVariousSchemaTypesListTypeTest_RequestStruct_LiteralSerializer.java:50)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.internalDeserialize(LiteralObjectSerializerBase.java:233)
at com.sun.xml.rpc.encoding.literal.LiteralObjectSerializerBase.deserialize(LiteralObjectSerializerBase.java:141)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.NewSchemaTest_2_Tie.deserialize_echoVariousSchemaTypesListTypeTest(NewSchemaTest_2_Tie.java:3324)
at com.sun.ts.tests.jaxrpc.ee.wsi.rpc.literal.marshalltest.NewSchemaTest_2_Tie.readFirstBodyElement(NewSchemaTest_2_Tie.java:2626)
at com.sun.xml.rpc.server.StreamingHandler.handle(StreamingHandler.java:262)
at com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(JAXRPCServletDelegate.java:465)



 Comments   
Comment by Lukas Jungmann [ 26/Jul/12 ]

fixed in r55219





[GLASSFISH-18766] Memory leak in jsr109impl Created: 29/May/12  Updated: 09/Feb/13  Resolved: 08/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b23, 3.1.2
Fix Version/s: 4.0_b75

Type: Bug Priority: Critical
Reporter: michail.nikolaev Assignee: Lukas Jungmann
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Usage of @WebService causes to memory leak on every endppoint call.

Cause of problem:
org.glassfish.webservices.InstanceResolverImpl<T>

On the call to
@Override
public Object invoke(Packet p, Method m, Object... args) throws InvocationTargetException, IllegalAccessException

{ return m.invoke( resolve(p), args ); }

it calls "resolve" method, which calls injManager.createManagedObject(classtobeResolved); and creates new managed object and stores in the class field.

Also, one of our Spring-based application works normal way, for some reason com.sun.xml.ws.server.SingletonResolver is used instead of InstanceResolverImpl.

There is the dispose method, which can destroy it appropriate way. But it will be called only in case of call to SEIInvokerTube.preDestroy. As I know it is only called while endpoint unregestering.

So, on every new call to endpoint, InstanceResolverImpl create new managed object without attempt to destroy previous. After a week of our JVM contains about 200000 of such objects.

So, to fix it more fast way "resolve" of InstanceResolverImpl method may to be changed to:

public @NotNull T resolve(Packet request) {
//See iss 9721
//Injection and instantiation is now done lazily

try {
// NEW STARTS HERE
if (instance != null)

{ injManager.destroyManagedObject(instance); instance = null; // to be sure will not be reused in case of exception inside createManagedObject }

// NEW ENDS HERE
instance = injManager.createManagedObject(classtobeResolved);
} catch (InjectionException e)

{ throw new WebServiceException(e); }

resolver = InstanceResolver.createSingleton(instance);
getResourceInjector(endpoint).inject(wsc, instance);
return resolver.resolve(request);
}



 Comments   
Comment by michail.nikolaev [ 29/May/12 ]

There is a possible temporal workaround:

1) add to dependency

<dependency>
<groupId>org.glassfish.main.common</groupId>
<artifactId>container-common</artifactId>
<version>3.1.2</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>org.glassfish.main.webservices</groupId>
<artifactId>jsr109-impl</artifactId>
<version>3.1.2</version>
<scope>provided</scope>
</dependency>

2) Create class like
public class WebSingletonResolver<T> extends InstanceResolver<T> {
private final Class<T> clazzToBeResolved;
private final InjectionManager injManager =
WebServiceContractImpl.getInstance().getHabitat().getByContract(InjectionManager.class);
private final ThreadLocal<T> instance = new ThreadLocal<T>();
private WSEndpoint endpoint;
private WSWebServiceContext wsc;

public WebSingletonResolver(@NotNull Class<T> clazz)

{ this.clazzToBeResolved = clazz; }

public @NotNull
T resolve(Packet request) {
if (instance.get() != null)

{ return instance.get(); }

init();

return instance.get();
}

private void init() {
try

{ instance.set(injManager.createManagedObject(clazzToBeResolved)); }

catch (InjectionException e)

{ throw new WebServiceException(e); }

getResourceInjector(endpoint).inject(wsc, instance.get());
}

public void start(WSWebServiceContext wsc, WSEndpoint endpoint) { this.wsc = wsc; this.endpoint = endpoint; }

public void dispose() {
try {
if (instance.get() != null) { // instance can be null as it is created laziily injManager.destroyManagedObject(instance.get()); instance.set(null); }
} catch (InjectionException e) { throw new WebServiceException(e); }

}

private ResourceInjector getResourceInjector(WSEndpoint endpoint) {
ResourceInjector ri = endpoint.getContainer().getSPI(ResourceInjector.class);
if (ri == null)

{ ri = ResourceInjector.STANDALONE; }

return ri;
}
}
3) create annotation like
@InstanceResolverAnnotation(WebSingletonResolver.class) @Target(TYPE) @Retention(RUNTIME)
public @interface WebSingleton {
}
4) annotate endpoint like
@WebService(serviceName = "XXXXService",
endpointInterface = "com.xxx.XXXXService",
targetNamespace = "http://xxx.com/")
@WebSingleton

Comment by shreedhar_ganapathy [ 13/Dec/12 ]

Possible WS impl bug. Reassign if not appropriate

Comment by Martin Grebac [ 02/Jan/13 ]

Lukasi, would you please evaluate this? Thanks.

Comment by Lukas Jungmann [ 08/Feb/13 ]

http://java.net/projects/glassfish/sources/svn/revision/59316





[GLASSFISH-18752] The value from webservice HTTP response and client are not same Created: 22/May/12  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b36
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: tak09 Assignee: Lukas Jungmann
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 7


Attachments: Zip Archive send.zip    
Tags: metro2_2_1-waived

 Description   

The value from webservice HTTP response and client are not same.

Steps reproduce:

  1. Extract the attached zip file.
  2. Deploy the attached file.
    C:\temp>asadmin deploy jaxws-w2j-08-web.war
  3. Execute wsimport
    C:\temp\src>wsimport -keep -p client http://localhost:8080/jaxws-w2j-08-web/AddNumbersImplService?wsdl
  4. Compile client.
    C:\temp\src>javac client*.java
  5. Run client
    C:\temp\src>java client.AddNumbersClient
    ==========The result is: 0==========

However, if you use a tcpmon tool to monitor the HTTP response XML, the result value in HTTP response is 30. In the client the result value is 0.

HTTP/1.1 200 OK
Content-Type: text/xml;charset=utf-8
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Sun Microsystems Inc./1.6)
Server: GlassFish Server Open Source Edition 4.0
Date: Tue, 22 May 2012 06:08:58 GMT
Transfer-Encoding: chunked

6e
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
e4
<ns2:addNumbersResponse xmlns:ns2="http://duke.example.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">
30 *********************** Please see here. The result in HTTP response is 30 , but in the client it is 0. ******************
</ns2:addNumbersResponse>
</S:Body>
</S:Envelope>
0



 Comments   
Comment by Lukas Jungmann [ 06/Mar/13 ]

Sample does not seem to be valid or at lease sources and binaries do not match.

there is also following problem with attached sources:
-AddNumbersImpl says it 'implements' AddNumbersPortType (through @webService.endpointInterface) but it does not override method defined there - String add_0020Numbers(AddNumbers x) vs AddNumbersResponse add_0020Numbers(... AddNumbers x)
-AddNumbersResponse holds 'int' value but web method is implemented to return String - this is another mismatch

I tried to fix this by letting both methods return AddNumbersResponse, fixed implementation of web method and changed the type of the '_return' field in AddNumbersResponse to String and everything is working correctly.

Feel free to reopen with fixed sample if you can still reproduce this.

Thanks.





[GLASSFISH-18751]  wsgen and wsimport do not work due to tool.jar not found error Created: 22/May/12  Updated: 29/Apr/13  Resolved: 11/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1
Fix Version/s: 4.0_b75

Type: Bug Priority: Major
Reporter: tak09 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,762
Tags: metro2_2_1-waived

 Description   

run those command will show some messages, but we couldn't find them in
glassfish workspace:

C:\glassfish3\glassfish\bin>wsgen
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually th
is means you are running JRE, not JDK. Please use the java command in JDK 5.0 or
later (not JRE.)

  • This command executes com.sun.tools.ws.WsGen could not find iWsGen.java in
    source code
    -------------------------------------------------

C:\glassfish3\glassfish\bin>wsimport
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually th
is means you are running JRE, not JDK. Please use the java command in JDK 5.0 or
later (not JRE.)

-same, could not find com.sun.tools.ws.WsImport.java
-------------------------------------------------

C:\glassfish3\glassfish\bin>schemagen
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually th
is means you are running JRE, not JDK. Please use the java command in JDK 5.0 or
later (not JRE.)

-same, could not find com.sun.tools.jxc.SchemaGeneratorFacade.java



 Comments   
Comment by tak09 [ 22/May/12 ]

wsimport and wsgen do not work due to tool.jar not found error. I found GLASSFISH-13762 and the status is resolved but it's still not working.

GlassFish version is 4.0 b36

Comment by tak09 [ 22/May/12 ]

With version 4.0, wsimport and wsgen fails with this error, but schemagen works.

C:\glassfish\glassfish-4.0-b36\glassfish3\glassfish\bin>wsimport
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually this means you are run
ning JRE, not JDK. Please use the java command in JDK 5.0 or later (not JRE.)

C:\glassfish\glassfish-4.0-b36\glassfish3\glassfish\bin>wsgen
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually this means you are run
ning JRE, not JDK. Please use the java command in JDK 5.0 or later (not JRE.)

C:\glassfish\glassfish-4.0-b36\glassfish3\glassfish\bin>schemagen
Usage: schemagen [-options ...] <java files>
Options:
-d <path> : specify where to place processor and javac generated class files
-cp <path> : specify where to find user specified files
-classpath <path> : specify where to find user specified files
-encoding <encoding> : specify encoding to be used for annotation processing/javac invocation
-episode <file> : generate episode file for separate compilation
-version : display version information
-fullversion : display full version information
-help : display this usage message

Comment by emailnbw [ 22/May/12 ]

This is broken in 3.1.2 FCS as well. I am running JDK 1.7.0_03 x64 on Windows 7.

As a work around I was able to use \Program Files\Java\jdk1.7.0_03\bin\wsimport.exe instead.

Comment by Lukas Jungmann [ 22/May/12 ]

could be related to space in path (..."program files"...) as I was not able to reproduce this earlier today while having JDK in "d:\java\sdk\jdk1.7.0_04", will try again with JDK in the default location

Comment by tak09 [ 23/May/12 ]

My JDK is installed in C:\Program Files\Java\jdk1.6.0_26

I copied the C:\Program Files\Java\jdk1.6.0_26\lib to C:\Program Files\Java\lib as a workaround.

Comment by Lukas Jungmann [ 11/Feb/13 ]

a try to fix this issue - if asadmin is working properly, ws tools should be working as well as they're now using same $JAVA_HOME:

http://java.net/projects/glassfish/sources/svn/revision/59360

Comment by tak09 [ 26/Mar/13 ]

Hi Lukas,

I've downloaded glassfish-4.0-b81-03_20_2013, but it's not working for me.

C:\>C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\wsimport.bat
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually this means you are run
ning JRE, not JDK. Please use the java command in JDK 5.0 or later (not JRE.)

When wsimport is executed from other directory, it looks working. However, JDK's wsimport is called. It's not glassfish wsimport.

C:\>"C:\Program Files\Java\jdk1.7.0_17\bin\wsimport.exe"
Missing WSDL_URI

Usage: wsimport [options] <WSDL_URI>

where [options] include:
-b <path> specify jaxws/jaxb binding files or additional schemas
(Each <path> must have its own -b)
-B<jaxbOption> Pass this option to JAXB schema compiler
.....

Comment by Lukas Jungmann [ 26/Mar/13 ]

Is asadmin.bat working?
if you run 'echo %PATH%' what is printed out?
if you run 'echo %JAVA_HOME%' what is printed out?
if you run 'where java.*' what is printed out?
if you run 'where wsimport.*' what is printed out?

Comment by tak09 [ 26/Mar/13 ]

Hi Lukas,

asadmin is working. Please see below for the outputs.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\>where asadmin.bat
C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\asadmin.bat

C:\>asadmin start-domain
Waiting for domain1 to start ...............................
Successfully started the domain : domain1
domain Location: C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\domains\domain1
Log File: C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\domains\domain1\logs\server
.log
Admin Port: 4848
Command start-domain executed successfully.

C:\>echo %PATH%
C:\SFWCLNT\JDBC\fjjdbc\bin;C:\Program Files\CollabNet\Subversion Client;C:\Program Files (x86)\Commo
n Files\NetSarang;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\Window
sPowerShell\v1.0\;C:\Program Files\CA\SharedComponents\ScanEngine;C:\Program Files\CA\SharedComponen
ts\CAUpdate\;C:\Program Files\CA\SharedComponents\ThirdParty\;C:\Program Files\CA\SharedComponents\S
ubscriptionLicense\;C:\Program Files\CA\eTrustITM;C:\Program Files (x86)\Borland\StarTeam SDK 9.3\Li
b;C:\Program Files (x86)\Borland\StarTeam SDK 9.3\Bin;C:\Program Files (x86)\Enterprise Vault\EVClie
nt\;C:\Program Files (x86)\Mozilla Firefox;C:\Program Files\Java\jdk1.7.0_17\bin;c:\ant\bin;C:\Progr
am Files (x86)\Gow\bin;c:\ntutil\bin;c:\usr\bin;C:\Program Files (x86)\Hidemaru;C:\Program Files\Tor
toiseSVN\bin;C:\SFWCLNT\ESQL\BIN;C:\Windows\ESQL\BIN;C:\SFWCM\CM\BIN;C:\glassfish\glassfish-4.0-b81-
03_20_2013\glassfish4\glassfish\bin;C:\Program Files (x86)\QuickTime\QTSystem\;C:\SeleniumIEdriver;C
:\Program Files\TortoiseGit\bin

C:\>echo %JAVA_HOME%
C:\Program Files\Java\jdk1.7.0_17

C:\>where java.*
C:\Windows\System32\java.exe
C:\Program Files\Java\jdk1.7.0_17\bin\java.exe

C:\>where wsimport.*
C:\Program Files\Java\jdk1.7.0_17\bin\wsimport.exe
C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\wsimport
C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\wsimport.bat

C:\>where wsgen.*
C:\Program Files\Java\jdk1.7.0_17\bin\wsgen.exe
C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\wsgen
C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\wsgen.bat

C:\>

Comment by Lukas Jungmann [ 26/Mar/13 ]

Thanks!

So it's clear that on your path there is JDK/bin first, glassfish/bin second - if you change the order, does it help?

btw: one thing I've just noticed and cannot check it immediately - you run C:\>C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\wsimport.bat - if you do 'cd C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin' and then call wsimport - does it change anything?

Comment by tak09 [ 26/Mar/13 ]

I changed the order of path. It is now glassfish/bin first, then JDK/bin.

Please see the output.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\>echo %PATH%
C:\SFWCLNT\JDBC\fjjdbc\bin;C:\Program Files\CollabNet\Subversion Client;C:\Program Files (x86)\Commo
n Files\NetSarang;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\Window
sPowerShell\v1.0\;C:\Program Files\CA\SharedComponents\ScanEngine;C:\Program Files\CA\SharedComponen
ts\CAUpdate\;C:\Program Files\CA\SharedComponents\ThirdParty\;C:\Program Files\CA\SharedComponents\S
ubscriptionLicense\;C:\Program Files\CA\eTrustITM;C:\Program Files (x86)\Borland\StarTeam SDK 9.3\Li
b;C:\Program Files (x86)\Borland\StarTeam SDK 9.3\Bin;C:\Program Files (x86)\Enterprise Vault\EVClie
nt\;C:\Program Files (x86)\Mozilla Firefox;C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glas
sfish\bin;C:\Program Files\Java\jdk1.7.0_17\bin;c:\ant\bin;C:\Program Files (x86)\Gow\bin;c:\ntutil\
bin;c:\usr\bin;C:\Program Files (x86)\Hidemaru;C:\Program Files\TortoiseSVN\bin;C:\SFWCLNT\ESQL\BIN;
C:\Windows\ESQL\BIN;C:\SFWCM\CM\BIN;C:\Program Files (x86)\QuickTime\QTSystem\;C:\SeleniumIEdriver;C
:\Program Files\TortoiseGit\bin

C:\>wsimport
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually this means you are run
ning JRE, not JDK. Please use the java command in JDK 5.0 or later (not JRE.)

C:\>C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\wsimport.bat
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually this means you are run
ning JRE, not JDK. Please use the java command in JDK 5.0 or later (not JRE.)

C:\>cd C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin\

C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin>wsimport
JDK's tools.jar was not found in C:\Program Files\Java\lib\tools.jar. Usually this means you are run
ning JRE, not JDK. Please use the java command in JDK 5.0 or later (not JRE.)

C:\glassfish\glassfish-4.0-b81-03_20_2013\glassfish4\glassfish\bin>

Comment by tak09 [ 29/Apr/13 ]

When are you fixing this one? I have downloaded Glassfish b87 04_25_2013 but this bug is not fixed yet.





[GLASSFISH-18743] Webservice deploy error message when <port-component-name> is incorrect Created: 21/May/12  Updated: 12/Feb/13  Resolved: 12/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b36
Fix Version/s: 4.0_b75

Type: Improvement Priority: Minor
Reporter: tak09 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: File wsdltojava-web.war    
Issue Links:
Related
is related to GLASSFISH-19559 asadmin deploy failed Resolved

 Description   

If webservices.xml <port-component-name> and the actual classname are different, the following error message is displayed on deployment. It is difficult for a user to find the cause.

C:\temp>asadmin deploy wsdltojava-web.war
remote failure: Error occurred during deployment: Exception while preparing the app : Servlet HelloI
mpl implements 2 web service endpoints but must only implement 1. Please see server.log for more de
tails.
Command deploy failed.

In this example, port-component-name is Hello, but it should be HelloImpl.
<port-component-name>Hello</port-component-name>
If you deploy the attached war file, you will get this error. Then, if you change the port-component-name to HelloPort, deployment will succeed.



 Comments   
Comment by Lukas Jungmann [ 12/Feb/13 ]

severe log message added in http://java.net/projects/glassfish/sources/svn/revision/59408





[GLASSFISH-18742] endpoint name is missing in a deployment error message. Servlet web service endpoint '' failure. Created: 21/May/12  Updated: 12/Feb/13  Resolved: 12/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b36
Fix Version/s: 4.0_b74

Type: Bug Priority: Trivial
Reporter: tak09 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File web.war    

 Description   

asadmin deploy

endpoint name is missing. Servlet web service endpoint '' failure.
Please deploy the sample war file to reproduce the problem.

C:temp\>asadmin deploy web.war
remote failure: Error occurred during deployment: Exception while loading the app : java.lang.Illega
lStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.Ru
ntimeException: Servlet web service endpoint '' failure. Please see server.log for more details.
Command deploy failed.


 Comments   
Comment by Lukas Jungmann [ 12/Feb/13 ]

already fixed





[GLASSFISH-18740] Webservice stacktrace is not included in the HTTP response even if com.sun.xml.ws.fault.SOAPFaultBuilder.enableCaptureStackTrace is true Created: 18/May/12  Updated: 01/Aug/12  Resolved: 01/Aug/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b36
Fix Version/s: 4.0_b48

Type: Bug Priority: Major
Reporter: tak09 Assignee: Lukas Jungmann
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: File jaxws-w2j-03-web.war     Zip Archive src.zip    
Issue Links:
Dependency
depends on JAX_WS-1076 disableCaptureStackTrace vs captureSt... Resolved
Tags: metro2_2_1-waived

 Description   

Problem 1
In GlassFish v2.1.2, the HTTP response contains stacktrace from server.
However, in GlassFish v4, stacktrace is not included in the HTTP response.
First, I have set jvm option -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.enableCaptureStackTrace=true in GFv4, but the stacktrace was not in the HTTP response.

Then, I saw this bug ticket. http://java.net/jira/browse/JAX_WS-883
I set another jvm option -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.captureStackTrace=true in GFv4.
I ran the test program again, but still did not see stacktrace in HTTP response.

Problem 2
In GFv2.1.2, stactrace is written in the server.log, but in GFv4, stacktrace is not written in server.log.

To reproduce the issue:
First, follow the steps below using GlassFish v4.

  1. Deploy the war file.
    • Start GlassFish asadmin start-domain
    • Deploy the attached war file. (jaxws-w2j-03-web.war)
  2. Prepare client program
  3. Run Client to confirm test program works
    • Run client
      > java fromwsdl.client.AddNumbersClient
    • You will see the message like this:
      "Caught AddNumbersFault_Exception: Numbers: -10, 20"
  4. Verify the result
    • Problem 1: Check the xml HTTP response data sent from server.
      You might want to use a tool such as TCPMon to see the raw data in xml. The xml does not contain stacktrace if GFv4.
    • Problem 2: Check the server.log . The log does not have stacktrace if GFv4.
  5. Set the jvm options.
    • Open domain.xml and set the following jvm options.
      -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.captureStackTrace=true
      -Dcom.sun.xml.ws.fault.SOAPFaultBuilder.enableCaptureStackTrace=true
  6. Restart GlassFish
  7. Verify the jvm options
    • Run the client again.
    • Check the HTTP response. The HTTP response does not include stacktrace if GFv4.
    • Check the server.log. server.log does not contain stacktrace if GFv4.

Once this is finished with GlassFish v4, repeat the same step using GlassFish v2.1.2. Compare the HTTP response. You will see the stacktrace in the HTTP response xml in GFv2. Compare the server.log as well, you will also find the stacktrace in server.log if GFv2.1.2.

Why stacktrace is not recorded in server.log or not included in HTTP response in v4? That used to work in v2.1.2.



 Comments   
Comment by Lukas Jungmann [ 01/Aug/12 ]

this works as designed - JAX-WS RI docs will be updated (JAX_WS-1076)

server-side stack traces are still being sent but not by default (set com.sun.xml.ws.fault.SOAPFaultBuilder.captureStackTrace=true to turn it on) and when it is set to 'on', only stack traces of exceptions which are not service-specific are being sent. To apply this to attached sample app - AddNumbersFaultException is service specific exception and ws developer can set its message to provide necessary info, if AddNumbersFaultException is replaced by ie RuntimeException stacktrace is sent as well as shown in the server log

this change has been made in issue JAX_WS-761





[GLASSFISH-18737] deploying a webserivce failed when there is a space in schemaLocation Created: 17/May/12  Updated: 13/Feb/13  Resolved: 13/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b36
Fix Version/s: 4.0_b75

Type: Bug Priority: Minor
Reporter: tak09 Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: File path_014-web.war    

 Description   

On GlassFish v4.0, deploying webservice failed if there are space characters in schemaLocation. This used to work on GlassFish v2.1.2. Sample war file is attached.

On GlassFish v4.0 b36
C:\temp>asadmin deploy path_014-web.war
remote failure: Error occurred during deployment: Exception while loading the app : java.lang.Illega
lStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.Ru
ntimeException: Servlet web service endpoint '' failure. Please see server.log for more details.
Command deploy failed.

On GlassFish v2.1.2
C:\temp>asadmin deploy path_014-web.war
Command deploy executed successfully.



 Comments   
Comment by Lukas Jungmann [ 13/Feb/13 ]

http://java.net/projects/glassfish/sources/svn/revision/59441





[GLASSFISH-18678] weblogic-webservices.xml webservice-type="JAXWS" results in SEVERE error message Created: 02/May/12  Updated: 12/Jun/12  Resolved: 07/Jun/12

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b41

Type: Bug Priority: Major
Reporter: edrandall Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.6.0_31; Windows 7; Linux; Solaris


Attachments: Text File gf18678-test.diff.txt     Text File gf18678.diff.txt    
Tags: deployment, metro-gf313-target, weblogic-webservices, webservices

 Description   

Our application is intended to run under a number of different application servers.

In weblogic-webservices.xml we have all our web services listed with:
<webservice-type>JAXWS</webservice-type>

On deployment in Glassfish 3, this causes the following SEVERE error:
[#|2012-05-02T14:24:44.737+0000|SEVERE|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=19;_ThreadName=Thread-2;|WS00057: WebService type is declared as JAXWS but should be either JAX-WS or JAX-RPC|#]

Changing the value from JAXWS to JAX-WS makes this error go away (in Glassfish) but that contravenes the weblogic-webservices.xsd:
<xsd:restriction base="xsd:string">
<xsd:enumeration value="JAXRPC"/>
<xsd:enumeration value="JAXWS"/>
</xsd:restriction>

Glassfish is not correctly mapping the Weblogic values to its own legal values. (Nor is it checking the file against its XSD).

This support in Glassfish 3 for Weblogic deployment descriptors is causing a problem, because we are unable to disable it.

In most cases we can prevent unexpected behaviour from happening by ensuring that a glassfish-specific file is always packaged, its presence inhibits processing of the weblogic files. But there is no Glassfish equivalent of weblogic-webservices.xml.

Could we have some means of disabling all weblogic deployment descriptor parsing?



 Comments   
Comment by Hong Zhang [ 02/May/12 ]

Assign to webservices team for initial evaluation to see if they can fix this issue or disable weblogic-webservicecs.xml at webservices level. If not, we will try to figure out a way to turn off weblogic-* DD parsing at deployment infrastructure level through a system property.

Comment by Lukas Jungmann [ 13/May/12 ]

Hi, can I ask for some simple app which would help me to reproduce this issue and check possible fix, please?
Thanks!

Comment by Lukas Jungmann [ 07/Jun/12 ]

proposed patch

Comment by Lukas Jungmann [ 07/Jun/12 ]

http://java.net/projects/glassfish/sources/svn/revision/54496
http://java.net/projects/glassfish/sources/svn/revision/54497





[GLASSFISH-18664] WebServiceDeployer.unload throws NullPointerException on EAR deployment Created: 26/Apr/12  Updated: 12/Oct/12  Resolved: 12/Oct/12

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sisirhc Assignee: Lukas Jungmann
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: incomplete

 Description   

A NullPointerException with the following stack trace is thrown when deploying an EAR with multiple modules (EJB, WAR) to Glassfish. The EAR originally contained 4 projects having stateless EJBs with a @WebService annotation. However, removing these projects from the EAR does not resolve the problem. I didn't succeed creating a test case yet but my main project keeps failing (unfortunately I can't share that).

[#|2012-04-26T15:50:32.309+0200|FINE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=61;_ThreadName=Thread-2;ClassName=org.glassfish.api.ActionReport;MethodName=failure;|Exception while shutting down application container
java.lang.NullPointerException
	at org.glassfish.webservices.WebServicesDeployer.unload(WebServicesDeployer.java:770)
	at org.glassfish.webservices.WebServicesDeployer.unload(WebServicesDeployer.java:99)
	at org.glassfish.internal.data.EngineRef.unload(EngineRef.java:150)
	at com.sun.enterprise.v3.server.ApplicationLifecycle$1.actOn(ApplicationLifecycle.java:287)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:465)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
	at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
	at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
	at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
	at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
	at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
	at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
	at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
	at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
	at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
	at java.lang.Thread.run(Thread.java:722)
|#]

[#|2012-04-26T15:50:32.310+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=61;_ThreadName=Thread-2;|Exception while shutting down application container|#]


 Comments   
Comment by Martin Grebac [ 03/May/12 ]

Can't proceed without any testcase or better description on how to reproduce the issue.





[GLASSFISH-18653] "The reference type is not supported" exception under Metro 2.2 Created: 23/Apr/12  Updated: 11/Jul/12  Resolved: 11/Jul/12

Status: Closed
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: natashenko Assignee: Nithya Ramakrishnan
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu server 11.10 and java 1.6


Attachments: Text File my_configs.txt    
Tags: metro2_2_1-waived

 Description   

Hello,
could you help me please with an issue that I get when I try to connect client with my WSIT web-service under Oracle glassfish 3.1.2 using Kerberos 5?

The exception that I get:
apr 04, 2012 5:32:01 PM com.sun.xml.ws.security.opt.impl.keyinfo.KerberosTokenBuilder process
SEVERE: WSS1803: The reference type is not supported
apr 04, 2012 5:32:01 PM com.sun.xml.ws.security.opt.impl.dsig.SignatureProcessor sign
SEVERE: WSS1701: Sign operation failed.
com.sun.xml.wss.XWSSecurityException: WSS1803: The reference type is not supported
at com.sun.xml.ws.security.opt.impl.keyinfo.KerberosTokenBuilder.process(KerberosTokenBuilder.java:100)
at com.sun.xml.ws.security.opt.impl.keyinfo.SymmetricTokenBuilder.process(SymmetricTokenBuilder.java:290)
at com.sun.xml.ws.security.opt.impl.dsig.TokenProcessor.process(TokenProcessor.java:190)
at com.sun.xml.ws.security.opt.impl.dsig.SignatureProcessor.sign(SignatureProcessor.java:109)
at com.sun.xml.wss.impl.filter.SignatureFilter.sign(SignatureFilter.java:631)
at com.sun.xml.wss.impl.filter.SignatureFilter.process(SignatureFilter.java:589)
at com.sun.xml.wss.impl.HarnessUtil.processWSSPolicy(HarnessUtil.java:93)
at com.sun.xml.wss.impl.HarnessUtil.processDeep(HarnessUtil.java:272)
at com.sun.xml.wss.impl.SecurityAnnotator.processMessagePolicy(SecurityAnnotator.java:189)
at com.sun.xml.wss.impl.SecurityAnnotator.secureMessage(SecurityAnnotator.java:150)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.secureOutboundMessage(SecurityTubeBase.java:397)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:311)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:240)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.client.Stub.process(Stub.java:319)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy44.hello(Unknown Source)
at client.Client.doTest(Client.java:16)
at client.Client.main(Client.java:7)

apr 04, 2012 5:32:01 PM com.sun.xml.wss.jaxws.impl.SecurityTubeBase secureOutboundMessage
SEVERE: WSSTUBE0024: Error in Securing Outbound Message.
com.sun.xml.wss.XWSSecurityException: WSS1803: The reference type is not supported
at com.sun.xml.ws.security.opt.impl.keyinfo.KerberosTokenBuilder.process(KerberosTokenBuilder.java:100)
at com.sun.xml.ws.security.opt.impl.keyinfo.SymmetricTokenBuilder.process(SymmetricTokenBuilder.java:290)
at com.sun.xml.ws.security.opt.impl.dsig.TokenProcessor.process(TokenProcessor.java:190)
at com.sun.xml.ws.security.opt.impl.dsig.SignatureProcessor.sign(SignatureProcessor.java:109)
at com.sun.xml.wss.impl.filter.SignatureFilter.sign(SignatureFilter.java:631)
at com.sun.xml.wss.impl.filter.SignatureFilter.process(SignatureFilter.java:589)
at com.sun.xml.wss.impl.HarnessUtil.processWSSPolicy(HarnessUtil.java:93)
at com.sun.xml.wss.impl.HarnessUtil.processDeep(HarnessUtil.java:272)
at com.sun.xml.wss.impl.SecurityAnnotator.processMessagePolicy(SecurityAnnotator.java:189)
at com.sun.xml.wss.impl.SecurityAnnotator.secureMessage(SecurityAnnotator.java:150)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.secureOutboundMessage(SecurityTubeBase.java:397)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:311)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:240)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.client.Stub.process(Stub.java:319)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy44.hello(Unknown Source)
at client.Client.doTest(Client.java:16)
at client.Client.main(Client.java:7)

apr 04, 2012 5:32:01 PM com.sun.xml.wss.jaxws.impl.SecurityClientTube processClientRequestPacket
SEVERE: WSSTUBE0024: Error in Securing Outbound Message.
com.sun.xml.wss.impl.WssSoapFaultException: WSS1803: The reference type is not supported
at com.sun.xml.wss.impl.SecurableSoapMessage.newSOAPFaultException(SecurableSoapMessage.java:336)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.secureOutboundMessage(SecurityTubeBase.java:402)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:311)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:240)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
EXCEPTION: WSSTUBE0024: Error in Securing Outbound Message.
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.client.Stub.process(Stub.java:319)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy44.hello(Unknown Source)
at client.Client.doTest(Client.java:16)
at client.Client.main(Client.java:7)
Caused by: com.sun.xml.wss.XWSSecurityException: WSS1803: The reference type is not supported
at com.sun.xml.ws.security.opt.impl.keyinfo.KerberosTokenBuilder.process(KerberosTokenBuilder.java:100)
at com.sun.xml.ws.security.opt.impl.keyinfo.SymmetricTokenBuilder.process(SymmetricTokenBuilder.java:290)
at com.sun.xml.ws.security.opt.impl.dsig.TokenProcessor.process(TokenProcessor.java:190)
at com.sun.xml.ws.security.opt.impl.dsig.SignatureProcessor.sign(SignatureProcessor.java:109)
at com.sun.xml.wss.impl.filter.SignatureFilter.sign(SignatureFilter.java:631)
at com.sun.xml.wss.impl.filter.SignatureFilter.process(SignatureFilter.java:589)
at com.sun.xml.wss.impl.HarnessUtil.processWSSPolicy(HarnessUtil.java:93)
at com.sun.xml.wss.impl.HarnessUtil.processDeep(HarnessUtil.java:272)
at com.sun.xml.wss.impl.SecurityAnnotator.processMessagePolicy(SecurityAnnotator.java:189)
at com.sun.xml.wss.impl.SecurityAnnotator.secureMessage(SecurityAnnotator.java:150)
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.secureOutboundMessage(SecurityTubeBase.java:397)
... 14 more

Glassfish and KDC is running under ubuntu server 11.10 and java 1.6, client - under ubuntu desktop 11.10 and java 1.6.

I used this page to configure kerberos: http://www.alittletooquiet.net/text/kerberos-on-ubuntu/
and this page to configure glassfish and my application: https://blogs.oracle.com/ashutosh/entry/running_kerberos_token_profile_s....

I watched topic http://www.java.net/node/695180 (Kerberos handling in 2.0) but it didn't help me.

I see (in wireshark) that client gets TGS ticket from KDC but doesn't send it to service (the exception occurs).



 Comments   
Comment by Nithya Ramakrishnan [ 11/Jul/12 ]

We tried to run our Kerberos SQE test with a similar policy as in this issue and it passes.

<sp:KerberosToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once">
<wsp:Policy>
<sp:RequireDerivedKeys />
<sp:WssGssKerberosV5ApReqToken11/>
</wsp:Policy>
</sp:KerberosToken>

It appears to be a configuration issue. Closing it as not reproducible.





[GLASSFISH-18643] JPA/eclipselink dependencies of metro should be separated out Created: 18/Apr/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.0_b72_EE7MS4

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: metro2_2_1-waived, spo

 Description   

Can anyone tell me why metro bundle (webservices-osgi.jar) requires javax.persistence and org.eclipselink packages? Should such code not be separated into their own bundle so that we won't pull in jpa when user wants to use webservices?



 Comments   
Comment by Bhakti Mehta [ 18/Apr/12 ]

Assigning to Lukas

Comment by Lukas Jungmann [ 18/Apr/12 ]

Martin can comment on this

Comment by Martin Grebac [ 18/Apr/12 ]

Yes, we plan to separate this out. Metro allows eclipselink moxy binding and as such depends on eclipselink and eclipselink depends on jpa afaik. Anyway, we do have better modularization of jsr109 / webservices osgi bundle on our task list.

Comment by Lukas Jungmann [ 18/Jan/13 ]

MOXy plugin has been separated out from the webservices-osgi.jar to standalone bundle which should started when required





[GLASSFISH-18631] multiple stax implementations in distribution Created: 16/Apr/12  Updated: 12/Oct/12  Resolved: 12/Oct/12

Status: Closed
Project: glassfish
Component/s: packaging, web_services
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude, spo

 Description   

Yet another bad packaging issue. Just noticed two woodstox implementations in glassfish distribution:
woodstox-osgi.jar and woostox-core-asl.jar






[GLASSFISH-18626] the log isn't informative when deploy a web services application failed Created: 13/Apr/12  Updated: 23/Jan/13  Resolved: 23/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0pe, 9.0peur1_dev, 9.0peur1, 9.1pe_dev, 9.1pe, 9.1peur1_dev, 9.1peur1, 9.1peur2_b03, 9.1peur2, 9.1.1_dev, 9.1.1, v2.1, v2.1.1_dev, v2.1.1, V3, v3.0.1, 3.1_b02, 3.1_ms01, 3.1_b03, 3.1_b05, 3.1_b06, 3.1_ms02, 3.1_b07, 3.1_b08, 3.1_b10, 3.1_ms03, 3.1_b12, 3.1_b13, 3.1_b14, 3.1_b15, 3.1_b16, 3.1_ms04, 3.1_b17, 3.1_b18, 3.1_b19, 3.1_b20, 3.1_ms05, 3.1_b21, 3.1_b22, 3.1_b23, 3.1_b24, 3.1_b25, 3.1_b26, 3.1_ms06, 3.1_b27, 3.1_b28, 3.1_b29, 3.1_b30, 3.1_b31, 3.1_b32, 3.1_ms07, 3.1_b33, 3.1_b34, 3.1_b35, 3.1_b36, 3.1_b37, 3.1_b38, 3.1_b39, 3.1_b40, 3.1_b41 , 3.1_b42, 3.1_b43, 3.1_ms08, 3.1, 3.1.1_b01, 3.1.1_b02, 3.1.1_b03 , 3.1.1_b04 , 3.1.1_b05, 3.1.1_b06 , 3.1.1_b07 , 3.1.1_b08,