[GLASSFISH-4021] Resouce Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) Created: 21/Jan/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container, web_services
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Bug Priority: Critical
Reporter: gfuser9999 Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,021
Tags: 3_1-exclude, 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

--------
Problem
--------
1. Resource injections fails when using HandlerChain that have a
EJB/Resource injected that is an EJB/JNDI. And one gets
"Handler xxxxx instance injection failed : Exception attempting to inject
Resolved Ejb-Ref xxxx/bean@jndi: - > xxxxx]

The issues is that assuming we have 2 EJB and we want to have

  • EJB B exposed as Webservice and handle a HandlerChain handler
    So we have
    @Stateless
    @WebService
    @HandlerChain(file = "handle.xml")
    public void EJBBBean { ... }
  • We do not care above EJB A
  • Note that the handler is
    public class handler implements SOAPHanlder { @EJB EJBBBean bean; .... }
  • Now when one deploy this depending on the ordering
    of initialization of EJB, sometimes
    EJBA, EJBB and this works but if sometimes it is
    EJBB, EJBA then resource injection fails
  • The issues is that the following happens where it seems when
    a EJB is exposed as WebService and have a handler,
    a) The EJB is created and the handler is created
    b) The handler will be injected but then the issue is
    that THERE is IT may be possible that at the time
    the dependency is not met (since EJBA is not loaded or initialized
    nor registered to the JNDI even)

com.sun.enterprise.InjectionException: Exception attempting to inject Resolved
Ejb-Ref org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class
org.test.ws.FailInjectionHandler
at
com.sun.enterprise.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:391)
at
com.sun.enterprise.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:206)
at
com.sun.enterprise.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:100)
at
com.sun.enterprise.webservice.WsUtil.processConfiguredHandlers(WsUtil.java:2529)
at
com.sun.enterprise.webservice.WsUtil.configureJAXWSServiceHandlers(WsUtil.java:2570)
at
com.sun.enterprise.webservice.EjbRuntimeEndpointInfo.prepareInvocation(EjbRuntimeEndpointInfo.java:294)
at
com.sun.enterprise.webservice.EjbRuntimeEndpointInfo.initRuntimeInfo(EjbRuntimeEndpointInfo.java:342)
at
com.sun.enterprise.webservice.WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint(WebServiceEjbEndpointRegistry.java:122)
at
com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:329)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:345)
at
com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:550)
at
com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:188)

  • Now, this problem does not seems to be that the system does not resolve ordering
    Since writing more EJB seems to say that the GF system tends to order the EJB
    module
    However, there seems to be some race or data structure ordering issue since
    that the EJB module loading sequence on every stop/start is different and
    it is possible to get a EJB processing order that does not work.

--------------------
Testcase and details
--------------------
1. Get the attached NB6 ejbdeptest.zip and deploy
This testcase have many a few EJB modules to make this easier to hit this
Deploy ejbdeptest.ear

2. Stop/Start (asadmin stop-domain/start-domain)
and look for the injection failure. (REPEAT until failure is SEEN)
(grep SEVERE)

3. [Unpredictable and repeat (2) until SEVERE happens like below]

[#......|SEVERE|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=20;_ThreadName=httpSSLWorkerThread-14849-2;_RequestID=3a6b0964-02e0-419f-acc0-49c651e2916b;|Handler
org.test.ws.FailInjectionHandler instance injection failed : Exception
attempting to inject Resolved Ejb-Ref
org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class
org.test.ws.FailInjectionHandler|#]

3. Note some tracing does indicate that Bean processing via getEjbDescriptors()
varies sometimes and below is a failure sequence. (It is unknown
why the behaviour on the EJB processed changes sometimes)

[#.....|INFO|sun-appserver9.1|javax.enterprise.system.co
re.classloading|_ThreadID=10;_ThreadName=main;|[DEBUG] AbstractLoader org.test.s
lsb.e0Bean org.test.slsb.b6Bean org.test.slsb.b3Bean org.test.slsb.b2Bean or
g.test.slsb.b4Bean org.test.slsb.b1Bean org.test.slsb.b5Bean org.test.slsb.b0
Bean org.test.slsb.e1Bean org.test.slsb.zfailBean org.test.slsb.z0Bean org.t
est.slsb.z1Bean org.test.slsb.e2Bean |#]



 Comments   
Comment by Hong Zhang [ 22/Jan/08 ]

Assign to Mahesh for initial investigation. Also addding Bhakti to the Cc.

Attaching CWeng's suggested solutions below:
=============================================
And so i suppose plain common-sense must be used (which would then indicate the
system should be able to tell that a Handler class is used by WebserviceX and
the Handler class need Y, so Y must be initialized by X.

Even if there is no LOAD order, one may presume that creation of ALL EJB should
be done first and then on 2nd part the creation of all Webservices that those
EJB expose is done.
At this point the EJB and Webservice step for a EJB is coupled together....

Comment by Mahesh Kannan [ 14/Feb/08 ]

The problem is that the handlers are created probably way too early.

The Container calls
WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint() during container
initialization time which causes the handlers to be instantiated (which inturn
causes injection). We need to delay the instantiation of the handlers till the
dependent EJBs are processed.

One way to do that is to provide two methods:
1. One to register the the EjbService endpoint which WILL NOT call
WsUtil.processConfiguredHandlers()

2. The other method (say createConfiguredHandlers()) can create and call
InjectionManager.injectInstance(handler)

Once the above methods are in place the StatelessContainer can call the second
method from doAfterApplicationDeployed().

I am assigning this to Bhakti to implement the above two methods.

Comment by Bhakti Mehta [ 15/Feb/08 ]

Looking into it

Comment by harpreet [ 09/Apr/08 ]

Based on input from Bhakti, assigning issue to next release

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by ramapulavarthi [ 01/Dec/10 ]

I have n't run any tests but seeing the code in v3.1, we should run into the same problem.
Can't forward port the patches CR6653050 and CR6750245 as the code in v3 is little different from v2.1.
The fix needs to go into EJB container code to change the way we intialize and load the ejb web services.

Comment by Bhakti Mehta [ 08/Dec/10 ]

Reassigning to Rama since he has already looked into this issue . My inclination is to exclude this for this release but will wait for Rama's input

Comment by ramapulavarthi [ 21/Dec/10 ]

This requires changes in EJB Container to change the way EJB ws are loaded and needs coordination with EJB team. Adding V3.1 excludes as this is risky to make this change now.

Comment by Nazrul [ 23/Dec/10 ]

This bug has been around for few releases now. Based on inputs from Bill, I am setting target for 3.2 release with P2 priority so that it gets fixed. If we do not want to fix this bug, please close it.

Comment by 8086 [ 25/Mar/12 ]

We have been waiting for a fix for three years now. As of now, our application needs to be redeployed until it works. This might take anywhere from 1 redeploy to 15 redeploys to get it working.

If you are not fixing it, is there a way to work around it in our code that can remove the pain of innumerous redeploys?

Comment by kumara [ 26/Mar/12 ]

-> Martin Grebac for evaluation.

Comment by Gail Risdal [ 31/May/13 ]

Added the following to the release notes:

Resource Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) (4021)

Description
EJB module deployment may fail when an EJB that is exposed as a web service, and which has a handler, is initialized before an EJB on which it has dependencies. This is caused by the way the EJB container initializes and loads EJB web services.

Workaround
EJB initialization usually happens in alphabetical order. Rename the EJBs so that the EJB exposed as a web service is initialized after the EJB on which it has dependencies.

In the following example, B is initialized first together with handler X, which expects C to be available but it is not, and deployment fails. The workaround is to rename B to D (for example), so lexicographically it follows C, in which case C should be initialized first and be available for injection to X.

EJB module sth:

@Stateless public class C

{...}
@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}

handlers.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>X</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

Handler:

</jws:handler-chains>
@EJB private C;
...}

Comment by Gail Risdal [ 05/Jun/13 ]

Fixed the example in the release notes (first line in the "Handler" section; release notes document has proper formatting/indentation):

EJB module sth:

@Stateless public class C

{...}
@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}

handlers.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>X</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

Handler:

public class X implements SOAPHandler<SOAPMessageContext>

{ @EJB private C; ...}




[GLASSFISH-3811] Allow easier sharing of JAXB entities between client & server applications Created: 26/Oct/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,811

 Description   

JAXB compiler already supports something called "Separtate compilation [1]."
This feature is currently not used when a web service is deployed in GlassFish.
I think GlassFish should use this to generate the episode file and make it
available in a well known location so that users can pass that as a binding file
while using wsimport utility. This will help the following use case:

I have developed a web service and hand written the custom Java classes that are
used in the service interface. Those classes have JAXB annotations. When I
deploy to GlassFish, the server generates the WSDL & the xsd and makes it
available in a well known place. In the client side, if I want to reuse the
server side Java classes, then either I have to manually delete wsimport
generated classes - which is painful and errorprone, or I have to hand-code the
episode file - which is an inconvenience.

[1] http://weblogs.java.net/blog/kohsuke/archive/2006/09/separate_compil.html



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-631] For SOAP12 binding(s), user has to pkg WSDL - this requirement needs to be removed Created: 03/May/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: jungicz Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Attachments: Text File AddNumbers.wsdl    
Issuezilla Id: 631

 Description   

[GlassFish b-47]

It seems to me that there's currently no support for SOAP12 bindings (in case
one is using JSR109 based deployment ). This applies for both cases:
java->wsdl, wsdl->java.

java->wsdl case:
I wrote simple webapp with following ws:

@WebService()
@BindingType("http://www.w3.org/2003/05/soap/bindings/HTTP/")
public class WebService12 {

/* Sample Web Service Operation */
@WebMethod(operationName="sample_operation")
public String operation(@WebParam(name="param_name") String param)

{ // implement the web service operation here return param; }

}

=> webapp w/ this websvc cannot be deployed (i tried NetBeans as well as asdmin
deploy) - one can find following in the server's log:

ADM1006:Uploading the file to:[/tmp/s1astempdomain1server-1336981763/SOAP12ws.war]
error: The -wsdl option cannot be used with SOAP1.2 bindings.
Try using "-wsdl:Xsoap1.2 -extension".
Class "ws.WebService12" binding: "http://www.w3.org/2003/05/soap/bindings/HTTP/".|#]
Exception occured in J2EEC Phase
com.sun.enterprise.deployment.backend.IASDeploymentException: WSGEN FAILED
at com.sun.enterprise.webservice.WsUtil.genWSInfo(WsUtil.java:2009)
at
com.sun.enterprise.deployment.backend.ModuleDeployer.loadDescriptors(ModuleDeployer.java:396)
...

wsdl->java case:
I created new websvc from wsdl (attached) using NetBeans5.5 beta in webapp.
This webapp can be successfuly deployed, but I cannot test my new websvc nor
create my own client for it - possible cause can be that wsdl is not updated
correctly - you can find "<soap12:address location="REPLACE_WITH_ACTUAL_URL"/>"
in wsdl of deployed ws.



 Comments   
Comment by jungicz [ 03/May/06 ]

Created an attachment (id=255)
wsdl for test

Comment by vijaysr [ 03/May/06 ]

fix in progress - will be available as part of the glassfish trunk and FCS
branch in a day. A sample test is also added in
glassfish/appserv-tests/devtests/webservice/annotations.soap12

Comment by vijaysr [ 03/May/06 ]

taking ownership

Comment by vijaysr [ 03/May/06 ]

fix will be checked in a day

Comment by vijaysr [ 03/May/06 ]

Fixed the bug as long as the WSDL is packaged; The default WSDL created if the
user does not package the WSDL is always SOAP1.1. For SOAP12, the user is
expected to generate wsdl using wsgen and package it.

Changing this bug to enhancement request so that this manual step need not be
expected from the user for SOAP12, java-wsdl case also

Comment by vijaysr [ 03/May/06 ]

change enhancement request

Comment by vijaysr [ 13/Mar/07 ]

Reassigning to Bhakti

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-574] Web Service Endpoint Specification Needs Improvement Created: 13/Apr/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: khookguy Assignee: mikeg
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 574

 Description   

See also this related issue: 482

The specification of web service endpoint in Glassfish needs to be rationalized
and professionalized. First of all, the default endpoint URL assigned to a web
service varies depending on whether you deploy it as an EJB endpoint or a
serlvet endpoint. There should be no difference. The default URL for a WAR
deployment is:

http://<hostname[:port]>/<web module>/<simple name of the Service Class>

Whereas, when using a EJB-JAR, it is:

http://<hostname[:port]>/<simple name of the Service Class> + "Service"/<simple
name of the Service Class>

In the WAR case, the module name is part of the URL, and in the EJB-JAR case, it
is not. I believe that the default behavior in both cases should look like the
EJB-JAR case. The file name of the web module should be irrelevant to deployment.

Secondly, the hostname selected by GlassFish is something of a mystery and is
outside the deployer's control. See this thread fron the SDN forum:
http://forum.java.sun.com/thread.jspa?threadID=725485&tstart=0

There needs to be a mechanism by which the deployer can specify the hostname
that gets used in the WSDL (other then providing the entire WSDL file). This is
a real showstopper problem if you need to publish a WSDL that works outside a
firewall and GlassFish is using an internal hostname that can't be resolved on
the WWW.

Thirdly, there needs to be a better way to specify a custom context-root for the
EJB-JAR deployment scenario. When deploying a WAR, you can use the asadmin
deploy command with the --contextroot flag. However, this isn't applicable in
the EJB-JAR case. For the EJB-JAR, it seems that the only way to do it is to
provide a sun-ejb-jar.xml deployment descriptor with an endpoint-address-uri set
to the context-root desired. In this case, I think that the --context-root flag
should also work for the EJB-JAR case, and the value provided by the deployer
should be inserted into the internally generated sun-ejb-jar.xml by GlassFish at
deploy time.



 Comments   
Comment by khookguy [ 14/Apr/06 ]

Correction:

The default URL for a WAR deployment is:

http://<hostname[:port]>/<web module>/<simple name of the Service Class>
+ "Service"

Comment by tomo_ikeda [ 17/Apr/06 ]

About first point, I don't think that Web Module is irrelevant.
End Point Address should include the Web Module name.
Because, if there are two or more Service Implementation Beans with the same
name in different Web Modules, End Point Addresses conflict.
For EJB model, module name may be irrelevant.
But as long as we conform to the servlet specification of Java EE, the Web
Module name should be a part of the http URL address.
The most important thing is to avoid name collisions.
So, I think that the default End Point Address should be :
http://<hostname[:port]>/<Web Module name>/<fully qualified name of the Service
Class>
FYI, default Service Class name is Service Implementation Bean name + "Service".

Comment by khookguy [ 18/Apr/06 ]

Regarding module name, I agree that it is fine as the default context-root for
avoiding name collisions. However, I believe that there needs to be a
consistent means (across servlet and EJB endpoints) that allows the deployer to
specify a context-root. For many Web Services applications, it is desirable to
be able to specify the endpoint address of the service to have a URL that
conforms to naming standards (or is just easy to read) that have nothing to do
with the fact that it is deployed on a Java EE 5 container.

Comment by vijaysr [ 13/Mar/07 ]

Reassigning to Mike

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-10705] Update list-sub-components command with web services info Created: 30/Oct/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: Nazrul Assignee: jitu
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,705

 Description   

Currently, in CLI, user can find out the deployed applications with
"list-components" command. Then, "list-sub-components" shows the meta data
(Servlet, JSP, EJB) of an application. This does not identify the Web Services
end points. We should update this command to include Web Services end-points and
the test url also. I am cc..ing Paul to see if REST web services end-point can
be identified as well in future.

After this is done in CLI, we should expose the same data from GUI application
page where we are showing the meta data. It will help to have an AMX API for GUI.

Please note the following:

  • We should discover the application artifacts from application repository under
    DAS (for GFv3, it means the single instance). The implementation should not
    require application to be deployed to DAS target (becomes a problem in GFv3.1).
  • The implementation should not rely on flashlight probe framework. Lets look at
    this problem as a discovery of application meta data from the repository instead
    of runtime monitoring exercise.

CLI Example:

----------------------------------------------------------
[dhcp-usca14-133-152:glassfish-v3-b68-full/glassfishv3/bin] nazrul% ./asadmin
list-components
Enter admin user name> admin
Enter admin password for user "admin">
hello-stateless-ejb <ejb>
servlet-stateless-ear <ear, ejb, web>
advancedMapping <ejb, web>

Command list-components executed successfully.

----------------------------------------------------------

dhcp-usca14-133-152:glassfish-v3-b68-full/glassfishv3/bin] nazrul% ./asadmin
list-sub-components
Enter admin user name> admin
Enter admin password for user "admin">
Enter the value for the modulename operand> advancedMapping
FacesServlet <JSP>
default <Servlet>
jsp <Servlet>
StatelessSessionBean <StatelessSessionBean>
TestServlet <Servlet>

Command list-sub-components executed successfully.
----------------------------------------------------------



 Comments   
Comment by Hong Zhang [ 30/Oct/09 ]

This is not a bug. This was what this command was intended to (get the ejb and
web components). Take a look at the man page and v2 behavior.

Marking it as an enhancement if we want to add additional functionality to the
command.

Comment by Anissa Lam [ 30/Oct/09 ]

I have been working with Hong on providing such API.
She has just committed some changes for me and I am about to test that out.

Comment by Anissa Lam [ 30/Oct/09 ]

oh, I missed the last part of the summary "with web esrvices info" when i made
the comment just now.

Hong has provided a way for GUI to list out the elements in the module, which is
the equivalent of "list-sub-components" command. I will test that out.

With this info, GUI will work with the web services team to support webservices
endpoint testing.

As for the the list-sub-components command with web services info, which is
what this ticket is for, I agree that this is an enhancement.

Comment by Anissa Lam [ 30/Oct/09 ]

sorry, i accidentally changed this to 'STARTED' state, and i can't seem to be
able to change it back to 'NEW'.

Comment by Nazrul [ 30/Oct/09 ]

Getting help from Jitu

Comment by Hong Zhang [ 23/Mar/11 ]

moving this issue under webservices category

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-12597] Web Service Tester not available for secure endpoints Created: 08/Jul/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: v3.0.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: catchwa Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive SecWSTester.zip    
Issuezilla Id: 12,597

 Description   

Steps to reproduce in NetBeans 6.9 (roughly based on
http://java.sun.com/webservices/reference/tutorials/wsit/doc/WSIT_Security9.html
#wp162511)

1. Create a new Web Application
2. Create a new Web Service
3. Add an operation to your web service
4. In the Edit Web Service Attributes dialog, tick Secure Service and select
Mutual Certificates Security. Leave the other security settings at their
Development Defaults.
5. Export the sample client key that is bundled with GlassFish into a PKCS12
certificate:

C:\glassfishv3\glassfish\domains\domain1\config>keytool -importkeystore -
srckeystore keystore.jks srcstoretype JKS -srcstorepass changeit -srcalias xws
security-client -destalias xws-security-client -deststoretype PKCS12 -
destkeystore client.p12

6. Import client.p12 into your web browser.
7. Deploy Web Service to GlassFish

Note that the following URLs work as expected
https://localhost:8181/SecWSTester/
https://localhost:8181/SecWSTester/NewWebServiceService
https://localhost:8181/SecWSTester/NewWebServiceService?wsdl

Note, however, that the Web Service Tester that is found at:
https://localhost:8181/SecWSTester/NewWebServiceService?Tester

just displays a blank page.

1.) As the Tester isn't currently available for secure endpoints GlassFish
should display a message to reflect this, rather than not giving any feedback
to the user/developer.

2.) As an enhancement, GlassFish should allow for Web Service Testing
functionality on secure endpoints.



 Comments   
Comment by catchwa [ 08/Jul/10 ]

Created an attachment (id=4555)
Sample NetBeans project (minus contents of the /lib directory to save space)

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5029] RFE: When web service tester catches an exception, output the casuing exception instead of the whole thing Created: 15/May/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: rdelaplante Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,029

 Description   

My web service threw an application exception. The web service tester outputted
a gigantic dump and I couldn't find useful error message until 20 lines or so
into it, after "caused by:". You should just output the causing exception, so
that the very first line I see is my application's exception and error message.

javax.servlet.ServletException: java.lang.reflect.InvocationTargetException at
com.sun.enterprise.webservice.monitoring.WebServiceTesterServlet.doPost(WebServiceTesterServlet.java:345)
at
com.sun.enterprise.webservice.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:121)
at
com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at
com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at
com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: 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.webservice.monitoring.WebServiceTesterServlet.doPost(WebServiceTesterServlet.java:316)
... 27 more Caused by:
com.ijws.webin.services.oncommand.OnCommandServiceException_Exception: Unable to
email folio to reservation '23800-01' at 'torph' because it is not already
checked out. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at
com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:127)
at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118) at
$Proxy193.emailFolio(Unknown Source) ... 32 more Caused by:

      • THIS IS WHAT I WANTED TO SEE ****

com.ijws.product.services.specific.SpecificServiceException: Unable to email
receipt to reservation '23800-01' at 'torph' because it is not <edited out>.... at

com.ijws.product.services.specific.SpecificService.emailReceipt(SpecificService.java:96)
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.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176) at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986) at
com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
at $Proxy186.emailFolio(Unknown Source) 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.webservice.InvokerImpl.invoke(InvokerImpl.java:81) at
com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82) at
com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) at
com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at
com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) at
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554) at
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539) at
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436) at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) at
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554) at
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539) at
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436) at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:317) at
com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
at
com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) at
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554) at
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539) at
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436) at
com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243) at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244) at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at
com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at
com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at
com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
at
com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at
com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at
com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at
com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:380)
... 2 more



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4271] Unified JSR 196 Security Created: 27/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: haroldcarr Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,271
Status Whiteboard:

v3-prd-item


 Description   

GF v3 PRD



 Comments   
Comment by haroldcarr [ 27/Feb/08 ]

Added v3-prd-item in status whiteboard

Comment by kumarjayanti [ 03/Sep/09 ]

Fixed.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4270] Kerberos interoperability with .NET 3.5 Created: 27/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: haroldcarr Assignee: kumarjayanti
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,270
Status Whiteboard:

v3-prd-item


 Description   

GF V3 PRD



 Comments   
Comment by haroldcarr [ 27/Feb/08 ]

Added v3-prd-item in status whiteboard

Comment by haroldcarr [ 27/Feb/08 ]

Change to FEATURE

Comment by ido_ran [ 13/Jun/09 ]
      • Issue 4270 has been confirmed by votes. ***
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-18170] [intermittent] [SC-RM] [Solaris 11] HA Failover test results in the fault "SequenceAcknowledgement violates the cumulative Acknowledgement invariant" Created: 11/Jan/12  Updated: 21/Sep/15

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

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

Attachments: Zip Archive 18170-oel6-logs.zip     Zip Archive 18170-solaris11-logs.zip     Zip Archive windows-run-logs.zip    
Tags: 312_qa, 3_1_2-exclude, metro2_2-waived

 Description   

GF 3.1.2 Build Used: 16
Setup: Cluster with 10 instances
Platform: Solaris 11
Has this passed before: Yes, on Solaris 10 with GF 3.1. Tests were not run on Solaris with GF 3.1.1. The test also passed on OEL6 with GF 3.1.2 build 17

Scenario:

  • Start a RM sequence with secure conversation enabled.
  • Send 3 messages of the sequence
  • Kill the serving instance
  • Send more messages that are part of the same sequence, after other instances have detected failure in the first serving instance.
  • Expectation: The instance to which the messages failover, is able to retrieve the sequence from its replica cache and continue the request/response without errors.

Observations:

  • The instance to which the messages failover, generates a fault - "The SequenceAcknowledgement violates the cumulative Acknowledgement invariant."
  • The following two differences were observed between the runs on Solaris 11 and on OEL6:

a) It appears that on Solaris 11, the 4th message that is sent from the client (see ant.output for client logs - look for "kill" and then scroll down to find the 4th message), seems to be received in the RM tube after a delay of about 18 seconds. While on OEL6, there isn't much of a difference. Below are logs from the Solaris 11 run.

        • ant.output (client log)
          [testng] Jan 10, 2012 6:40:27 AM com.sun.xml.ws.dump.MessageDumper dump
          [testng] INFO: Request message received in Tube [ com.sun.xml.ws.rx.rm.runtime.ClientTube ] Instance [ 2 ] Engine [ Metro/2.2-b12 (branches/2.2-6931; 2011-12-16T20:16:55+0000) JAXWS-RI/2.2.6-promoted-b14 JAXWS/2.2 svn-revision#unknown: Stub for http://ejp5363-vm1.india.sun.com:8080/symmetricbinding-rm/HelloWorldService ] Thread [ main ]:
          ****
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:40:44.098-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=29;_ThreadName=Thread-2;|Request message received in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 21 ] Engine [ com.sun.xml.ws.server.WSEndpointImpl@5fdc60 ] Thread [ http-thread-pool-28083(2) ]:
          ****

b) The other difference is related to the error that occurred. On Solaris 11, the response to Message number 4 contained an incorrect sequence acknowledgement range of 1..3 instead of 1..4. While on the run on OEL6 it was correct. Below is a log snippet from the Solaris 11 run.

        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:40:54.123-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=29;_ThreadName=Thread-2;|Response message processed in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 21 ] Engine [ com.sun.xml.ws.server.WSEndpointImpl@5fdc60 ] Thread [ http-thread-pool-28083(2) ]:
          ....
          <ns2:AcknowledgementRange Upper="3" Lower="1"/>
          </ns2:SequenceAcknowledgement>
          ****

An attempt at Analysis:

  • The incorrect sequence acknowledgement range seems to be related to the fault that is finally generated. Could it be caused due to slowness in handling Message number 4 (i.e. the first failed-over request on instance109 after instance101 failed) ? Its possible that it caused a back log of ack requests and so instance109 was unable to process the message correctly ?

Notes about the logs:

  • Logs will be attached to the bug. For instance logs see under st-cluster.
  • On the Solaris 11 run, the first serving instance was instance101 & the replica instance was instance109.
  • On the OEL6 run, the first serving instance was instance101 & the replica instance was instance105.


 Comments   
Comment by varunrupela [ 11/Jan/12 ]

Below are some detailed observations from the instance logs of the run on solaris 11:

  • The instance to which the messages failover (instance109), shows indications of receipt of the 4th request in its server log only after about 18 seconds of failure detection of the first serving instance (instance101).
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:40:44.098-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=29;_ThreadName=Thread-2;|Request message received in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 21 ] Engine [ com.sun.xml.ws.server.WSEndpointImpl@5fdc60 ] Thread [ http-thread-pool-28083(2) ]:
          ****

Between the time of failure detection and this point there seems to be some HA activity that is on.

        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:40:34.723-0800|FINER|glassfish3.1.2|com.sun.metro.commons|_ThreadID=27;_ThreadName=Thread-2;ClassName=[com.sun.xml.ws.commons.ha.HaContext] ;MethodName=validateRequest;|[METRO-HA] Thread[http-thread-pool-28083(3),5,grizzly-kernel] : Initialized from packet - replaced old HaState {packet=null, haInfo=null}

          with a new HaState{packet=com.sun.xml.ws.api.message.Packet@c424a4
          ****

  • The sequence data then seems to be retrieved from instance109's replica cache and the received message is processed.
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:40:45.156-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=33;_ThreadName=Thread-2;|Request message processed in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 30 ] Engine [ rm-server-tube-communicator ] Thread [ rm-server-tube-communicator-fiber-executor-thread-1 ]:
          ****
  • This is followed by instance109 receiving a number of AckRequested messages from the client.
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:40:45.156-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=33;_ThreadName=Thread-2;|Request message processed in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 30 ] Engine [ rm-server-tube-communicator ] Thread [ rm-server-tube-communicator-fiber-executor-thread-1 ]:
          ****
  • And then the Response message is received in tube:
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:40:45.252-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=33;_ThreadName=Thread-2;|Response message received in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 30 ] Engine [ rm-server-tube-communicator ] Thread [ rm-server-tube-communicator-fiber-executor-thread-1 ]:
          ****
  • The response message is processed but perhaps not completely. The Ack Range of messages received on the server side (Application Destination) still shows 1..3, while it should have updated to 1..4:
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:40:54.123-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=29;_ThreadName=Thread-2;|Response message processed in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 21 ] Engine [ com.sun.xml.ws.server.WSEndpointImpl@5fdc60 ] Thread [ http-thread-pool-28083(2) ]:
          ....
          <ns2:AcknowledgementRange Upper="3" Lower="1"/>
          </ns2:SequenceAcknowledgement>
          ****
          Possible the expected ack range for responses (sent from server side to test client) is also incorrectly 1..3, while the test client will soon end up receiving a 4th response
  • This is followed by a number of backed up AckRequested messages received at the server end and responded to.
  • Then comes in the next message in the sequence and with a sequence acknowledgement range of 1..4 (i think this indicates responses received on the App Source i.e. the test client side):
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:41:20.409-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=30;_ThreadName=Thread-2;|Request message received in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 29 ] Engine [ com.sun.xml.ws.server.WSEndpointImpl@5fdc60 ] Thread [ http-thread-pool-28083(1) ]:
          ....
          <ns5:AcknowledgementRange Upper="4" Lower="1"/>
          </ns5:SequenceAcknowledgement>
          ****
  • The below message then indicates an issue with the received message:
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:41:20.473-0800|WARNING|glassfish3.1.2|com.sun.metro.rx|_ThreadID=30;_ThreadName=Thread-2;|WSRM1125: "Message number [ 4 ] not found among the unacknowledged message numbers on a sequence [ uuid:b2f8149e-751b-4082-9801-ac6c92dffed8 ]."|#]
          ****
          I think this happens as the expected ack range for responses (sent from server side to test client) was only 1..3, while the test client indicates that a 4th response was also received.
  • A fault is then generated:
        • instance109's server.log_2012-01-10T06-41-21
          [#|2012-01-10T06:41:20.501-0800|INFO|glassfish3.1.2|com.sun.xml.ws.rx.rm.runtime.ServerTube|_ThreadID=30;_ThreadName=Thread-2;|Response message processed in Tube [ com.sun.xml.ws.rx.rm.runtime.ServerTube ] Instance [ 29 ] Engine [ com.sun.xml.ws.server.WSEndpointImpl@5fdc60 ] Thread [ http-thread-pool-28083(1) ]:
          ....
          <faultstring xml:lang="en">The SequenceAcknowledgement violates the cumulative Acknowledgement invariant.</faultstring>
          </SOAP-ENV:Fault>
          </S:Body>
          ****
Comment by Martin Grebac [ 11/Jan/12 ]

Hi Varun, is this the only failing test on Solaris 11? Is it a regression over 3.1.1?

Comment by varunrupela [ 11/Jan/12 ]

Yes. It is failing only on Solaris 11.
We ran the metro-HA tests on Solaris 10 with GF 3.1 and they had passed. Tests were not run on Solaris with GF 3.1.1.

Comment by sb110099 [ 19/Jan/12 ]

Just to clarify, Solaris 11 is a new platform in 3.1.2 .

Thanks,
Sudipa

Comment by varunrupela [ 20/Jan/12 ]

Observing the same failure on Windows 2008.
Logs have been attached.

  • In this case the first serving instance is instance102 and the failover instance is instance109.

The test has passed before with GF 3.1 on Windows 2008.

Comment by Martin Grebac [ 24/Jan/12 ]

Did the tests with 3.1 run on the same JDK? Is there an environment where we could debug this?

Comment by varunrupela [ 25/Jan/12 ]

A different JDK was used with GF 3.1 (JDK1.6.0_23)

Will send you mail with information on the available setup.

Comment by Martin Grebac [ 31/Jan/12 ]

Updating the bug as per discussion with Joe, adding 312 exclude keyword, removing review keyword since the issue is not a regression over 3.1/3.1.1 but an intermittent platform specific issue which makes it hard to debug.

We're not yet aware of what's the root cause, suspect it happens when message arrives to replica instance before the replica data is loaded and due to potential synch. issue the RM session data is overwritten.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Marek Potociar [ 08/Mar/13 ]

Assigning to Martin to reassign as appropriate since I no longer own the domain.

Comment by Martin Grebac [ 13/Mar/13 ]

Should be targeted to 4.0.1





[GLASSFISH-18406] @EJB injection fails but JNDI lookup works in web service class in Glassfish Created: 24/Feb/12  Updated: 21/Sep/15

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

Type: Improvement Priority: Major
Reporter: dwschulze Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2 beta built 2012-02-14, Windows 7 pro 64-bit, JDK 1.6


Attachments: Zip Archive reports.2012.02.24.zip    
Issue Links:
Related
is related to GLASSFISH-2105 EJB Web Service resource injection oc... Resolved
is related to GLASSFISH-2190 Resource injection fails. Resolved
Tags: metro2_2_1-waived

 Description   

I have a @WebService class that injects an @EJB. The EJB is packaged in a .jar file which is in the same .war file as the web service classes. The @EJB injection always fails, but I can do a JNDI lookup on the EJB. I've tried making the EJB and its interface @Remote, but that didn't matter. Injection still fails and JNDI lookup still works.

I'm using a version 3.0 web.xml. There's no ejb deployment descriptor in the ejb.jar file, but that is not suppose to matter in EJB 3.1.

EJB class and interface packaged in a .jar in the .war file:

//@Remote
public interface ReportServiceI {

public String testAlive();
}

@Stateless
//@Remote (ReportServiceI.class)
public class ReportService implements ReportServiceI

{...}

Web Service class:

@WebService(
targetNamespace = "http://www.reps.corp.com/services/reports/ReportService",
portName="ReportPort",
serviceName="ReportService",
endpointInterface="com.corp.reps.reports.ws.server.ReportServiceWSI")

public class ReportServiceWS implements ReportServiceWSI {

public static Logger logger = Logger.getLogger(ReportServiceWS.class);

// These all fail
// @EJB
// @EJB(beanInterface=ReportServiceI.class)
// @EJB(lookup="java:global/repsreports/ReportService")
ReportServiceI reportService;

public String testAlive() {

// this works
try

{ InitialContext context = new InitialContext(); reportService = (ReportServiceI)context.lookup("java:global/repsreports/ReportService"); }

catch (NamingException ex)

{ logger.error(ex); return "InitialContext.lookup() failed."; }

...

}



 Comments   
Comment by Cheng Fang [ 24/Feb/12 ]

If you make ReportServiceWS into EJB by adding @Stateless, does the injection work?

Comment by dwschulze [ 24/Feb/12 ]

Putting @Stateless on ReportServiceWS doesn't make any difference. All 3 forms of @EJB injection fail and the JNDI lookup succeeds.

I also want to avoid making ReportServiceWS a SessionBean for security reasons. The @WebService will be the only publicly visible interface into the system and I'm going to put WS-Security on those.

Comment by Cheng Fang [ 24/Feb/12 ]

Thanks for trying it. Can you attach a test app?

Comment by dwschulze [ 24/Feb/12 ]

I'll have to rename things (scrub proprietary names etc.).

Comment by dwschulze [ 24/Feb/12 ]

With Glassfish 3.1 or 3.1.2 running type mvn install in the top level reports project.

There is a Swing client in the reports.gui project. The main class is ReportsGUI. Run this GUI. Click on the second tab "Message Success Rate". Press the "Test Connectivity" button to verify that @EJB injection works.

The server side code is currently doing JNDI lookup which works. Comment out the init() method and uncomment one of the @EJB annotations to observe failure.

Comment by Cheng Fang [ 25/Feb/12 ]

I was able to reproduce the issue.

Note: need to use mvn 3.x to run the sample (mvn 2.2.1 failed). I also added some debug statement in @PostConstruct and @EJB setter method that can be displayed in server.log right after 'mvn install', without having to run the gui.

From my testing, @EJB injection into WebService class is not happening. That may explain why there is no injection-related errors or warnings.

Could be related to the two very old issues GLASSFISH-2190 and GLASSFISH-2105.

Comment by Cheng Fang [ 25/Feb/12 ]

assign to web services team to evaluate potential regression.

Comment by Bhakti Mehta [ 27/Feb/12 ]

Assigning to Lukas from the webservices team

Comment by Lukas Jungmann [ 28/Jun/12 ]

EJB injection in non-jsr109 deployment, which your app is using (it includes sun-jaxws.xml), is undefined, AFAIK => switching to enhancement

to "get around" this or better - implement your ws correctly - remove "proprietary" sun-jaxws.xml from your webapp as well as all relevant elements from web.xml (listener-class, servlet-class etc), they're not needed if you're deploying your app on glassfish





[GLASSFISH-18244] Web Service calls are not logged on server access log Created: 24/Jan/12  Updated: 08/Feb/13

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.1
Fix Version/s: future release

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

Issue Links:
Dependency
depends on GLASSFISH-19582 Move AccessLog support on Grizzly lev... Open
Tags: 3_1_2-exclude, metro2_3-exclude

 Description   

If you enable access logging on the HTTP Service, the generated access log only contains data for HTTP calls that are not Web Services calls.
For instance, if you deploy a JAX-WS enabled EJB and a Web application on the same server, the web application accesses will show up on the access log, but the EJB WS accesses will not.



 Comments   
Comment by Joe Di Pol [ 24/Jan/12 ]

Too late to fix in 3.1.2. Excluding.

Comment by Lukas Jungmann [ 24/Jan/13 ]

EJB endpoint is being registered using o.g.api.container.RequestDispatcher.registerEndpoint API. I'd expect that all services bound to underlied host/networklistener (ie accesslogging) become available to context being registered. Or is there some API I can use to send messages to PEAccessLogValve?

Thanks.

note that similar issue is there also for appclients (and logging access to generated JWS app URLs)

Comment by oleksiys [ 24/Jan/13 ]

related to http://java.net/jira/browse/GLASSFISH-19582





[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-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-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-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-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-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-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-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 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-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-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-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-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-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-11151] servlet-name needs to be FQCN Created: 23/Nov/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1
Fix Version/s: not determined

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,151
Status Whiteboard:

v3_exclude


 Description   

This is to keep track of this issue for 3.1
In WebserviceHandler since currently we are using
webComponent.setName(endpoint.getEndpointName()); this is generating the web.xml
without the FCQN.
As Rama mentioned
"This is making the existing TCK tests which use wrong servlet-name work.
I think the bug should be fixed as
webComponent.setName(endpoint.getEndpointName()); --->
webComponent.setCanonicalName(implClassFullName)"

However we are not going to make that change right now.



 Comments   
Comment by Bhakti Mehta [ 23/Nov/09 ]

Since this is a fix which is going to be targetted for v3.1 and it is risky to
make it right now we are marking as v3_exclude. Filing this bug for tracking purpose

Comment by Bhakti Mehta [ 23/Nov/09 ]

fixed a typo

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Bhakti Mehta [ 06/Mar/12 ]

Lukas, I have lost the context to the bug which made me file this issue and am not sure if this is valid anymore, feel free to close it otherwise.





[GLASSFISH-11381] StatefulWebServiceManager not injected in stateful web service Created: 02/Jan/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: widerstand Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,381

 Description   

I want to try to access a stateful web service.

The web service has a a public static field for the stateful manager:

public static StatefulWebServiceManager<TestServicesImpl> manager;

The web service is annotated with

@WebService(targetNamespace = "http://www.test.com/", name = "TestService")
@Stateful
@Addressing

The web service shows up in the admin console, but when I try to test it I get a
NPE. The manager field is null. So durign startup the injection does not seem to
work.



 Comments   
Comment by widerstand [ 02/Jan/10 ]

Major defect, so priority increased.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-9949] Fix warning of container implementing Module Created: 02/Oct/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Bhakti Mehta Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Duplicate
is duplicated by GLASSFISH-4479 doesn't support class com.sun.xml.ws.... Resolved
Issuezilla Id: 9,949

 Description   

https://jax-ws.dev.java.net/issues/show_bug.cgi?id=802



 Comments   
Comment by Bhakti Mehta [ 20/Oct/09 ]

In v3 when ejb and webservices are deployed WSEndpoint is created at that point
and also JAXWSContainer.
However we do not have the ServletContext at that point and hence the
JAXWSServletModule which extends ServletModule is null.
See JAXWSContainer code in v3 workspace.
This is same as v2 and will fix it once the higher priority ones are done

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-12945] The deployment of webservices archives failed: EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor Created: 10/Aug/10  Updated: 13/Dec/10

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

Type: Bug Priority: Minor
Reporter: easarina Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: Sun


Attachments: File hello-jaxws2.war     Java Archive File hello-singleton-ejb.jar     File hello-webserviceref.war     File hello-webserviceref.war    
Issuezilla Id: 12,945
Tags: 3_1-exclude

 Description   

Build 14. OEL linux: Linux jed-asqe-20 2.6.18-164.el5 #1 SMP Thu Sep 3 04:15:13
EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

Tried to deploy hello-jaxws2.war, hello-webserviceref.war, hello-singleton-ejb.jar.

In all these cases the deployment failed, for example:

remote failure: Exception while deploying the app :
java.lang.ClassCastException: com.sun.enterprise.deployment.EjbBundleDescriptor
cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor

Command deploy failed.

When I've executed the same deployment on RHL and Solaris everything was fine.
I will attach these archives.
-------------------------------------------------------------

[#|2010-08-10T14:39:18.150-0700|INFO|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Skipping
reparsin
g...file:/export/hudson/workspace/oel5g_rock/glassfishv3/glassfish/domains/domain1/applications/hello-webservicere
f/WEB-INF/classes/|#]

[#|2010-08-10T14:39:18.206-0700|WARNING|oracle-glassfish3.1|javax.enterprise.system.tools.deployment.org.glassfish
.deployment.common|_ThreadID=16;_ThreadName=Thread-1;|Error occurred
java.lang.NullPointerException
at
com.sun.enterprise.deployment.node.DeploymentDescriptorNode.writeDescriptor(DeploymentDescriptorNode.ja
va:486)
at
com.sun.enterprise.deployment.node.runtime.web.WLWebBundleRuntimeNode.writeDescriptor(WLWebBundleRuntim
eNode.java:167)
at
com.sun.enterprise.deployment.node.runtime.web.WLWebBundleRuntimeNode.writeDescriptor(WLWebBundleRuntim
eNode.java:57)
at
com.sun.enterprise.deployment.node.J2EEDocumentBuilder.getDocument(J2EEDocumentBuilder.java:110)
at
com.sun.enterprise.deployment.node.J2EEDocumentBuilder.write(J2EEDocumentBuilder.java:147)
at
com.sun.enterprise.deployment.node.J2EEDocumentBuilder.write(J2EEDocumentBuilder.java:136)
at
com.sun.enterprise.deployment.io.DeploymentDescriptorFile.write(DeploymentDescriptorFile.java:369)
at
com.sun.enterprise.deployment.archivist.Archivist.writeWLRuntimeDeploymentDescriptors(Archivist.java:10
10)
at
com.sun.enterprise.deployment.archivist.Archivist.writeExtraDeploymentDescriptors(Archivist.java:1028)
at
com.sun.enterprise.deployment.archivist.Archivist.writeDeploymentDescriptors(Archivist.java:944)
at
com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:172)
at
com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:79)
at
org.glassfish.javaee.core.deployment.DolProvider.saveAppDescriptor(DolProvider.java:256)
at
org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:183)
at
org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:82)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:652)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:594)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:296)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:208)
at
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:332)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:358)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:373)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1073)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:94)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1189)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1178)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:371)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:205)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:113)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:823)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:720)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2010-08-10T14:39:18.208-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|java.lang.Class
CastException: com.sun.enterprise.deployment.WebBundleDescriptor cannot be cast
to com.sun.enterprise.deployment.W
ebServicesDescriptor|#]

[#|2010-08-10T14:39:18.208-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.deployment.io.runtime.WLWebServicesDeploymentDescriptorFile.<init>(WLWebServicesDeploymentDescriptorFi
le.java:58)|#]

[#|2010-08-10T14:39:18.208-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.deployment.archivist.Archivist.writeWLWebServicesDescriptors(Archivist.java:1075)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.deployment.archivist.Archivist.writeWLRuntimeDeploymentDescriptors(Archivist.java:1017)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.deployment.archivist.Archivist.writeExtraDeploymentDescriptors(Archivist.java:1028)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.deployment.archivist.Archivist.writeDeploymentDescriptors(Archivist.java:944)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:172)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:79)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at org.gla
ssfish.javaee.core.deployment.DolProvider.saveAppDescriptor(DolProvider.java:256)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at org.gla
ssfish.javaee.core.deployment.DolProvider.load(DolProvider.java:183)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at org.gla
ssfish.javaee.core.deployment.DolProvider.load(DolProvider.java:82)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:652)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:594)|#]

[#|2010-08-10T14:39:18.209-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:296)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:208)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at org.gla
ssfish.deployment.admin.DeployCommand.execute(DeployCommand.java:332)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:358)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:373)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1073)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:94)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1189)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1178)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:371)|#]

[#|2010-08-10T14:39:18.210-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:205)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:113)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:823)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:720)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)|#]

[#|2010-08-10T14:39:18.211-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)|#]

[#|2010-08-10T14:39:18.212-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)|#]

[#|2010-08-10T14:39:18.212-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)|#]

[#|2010-08-10T14:39:18.212-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.ContextTask.run(ContextTask.java:69)|#]

[#|2010-08-10T14:39:18.212-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)|#]

[#|2010-08-10T14:39:18.212-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun
.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)|#]

[#|2010-08-10T14:39:18.212-0700|SEVERE|oracle-glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at java.la
ng.Thread.run(Thread.java:619)|#]

[#|2010-08-10T14:39:18.212-0700|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.serv
er|_ThreadID=16;_ThreadName=Thread-1;|Exception while deploying the app|#]

-bash-3.2$



 Comments   
Comment by easarina [ 10/Aug/10 ]

Created an attachment (id=4665)
hello-jaxws2.war

Comment by easarina [ 10/Aug/10 ]

Created an attachment (id=4666)
hello-webserviceref.war

Comment by easarina [ 10/Aug/10 ]

Created an attachment (id=4667)
hello-webserviceref.war

Comment by easarina [ 10/Aug/10 ]

Created an attachment (id=4668)
hello-singleton-ejb.jar

Comment by Hong Zhang [ 10/Aug/10 ]

Elena: did you set -Dwriteout.xml=true when you deploy the application? The
runtime deployment descriptors should not be written out by default, just
wondered how the stack trace got into the server.log.

I am reassigning the bug to webservices team for the main problem of
ClassCastException.

I am also Ccing Shingwai to the issue for the NPE in writing out the
weblogic.xml. I think he recently fixed something in this area.

Comment by easarina [ 10/Aug/10 ]

Yes, I've setup:

-Dwriteout.xml=true

Comment by easarina [ 13/Aug/10 ]

B15 RHL the deployment of all webservices archives failed with these messages.

On Solaris I was able to deploy webservices archives without any issues.

Comment by easarina [ 19/Aug/10 ]

Solaris 10 Sparc. Build 16 08/19.

When I've deployed webservices archives to the cluster, that had all instances
on one machine, I did not see this issue.

But when I've deployed webservices samples to the cluster that had two
instances on different machines. I saw this issue all time.

I've tried several times with different builds and always, as only a cluster
had instancs on different machines, that issue was seen.

Comment by easarina [ 04/Oct/10 ]

Please look at this issue.

Comment by Bhakti Mehta [ 05/Oct/10 ]

Please can you tell your steps how to reproduce
This is what I have tried on 2 machines

Das is my mac and instance1 is my hosted machine
asadmin create-cluster mycluster
asadmin create-node-config --nodehost adc2180404.us.oracle.com adcconf

asadmin update-node-config --installdir
/scratch/bhamehta/12945/glassfishv3/glassfish adcconf
asadmin create-instance --cluster mycluster --node adcconf mycluster_i1

on other machine
asadmin --host dhcp-santaclara22-1fl-west-10-132-178-100.usdhcp.oraclecorp.com
--port 4848 create-local-instance --node adcconf mycluster_i1
asadmin start-local-instance --node adcconf mycluster_i1

on my das
asadmin deploy --target mycluster ~/hello-jaxws2.war
Application deployed with name hello-jaxws2.

Command deploy executed successfully.

Now if i browse my instance machine
http://adc2180404:28080/hello-jaxws2.2/HelloService?wsdl that works fine

Comment by Bhakti Mehta [ 07/Oct/10 ]

I have tried 2 machines and that worked fine.
Next
I am using this machine which has the OEL . I have tried deployment without
cluster and with a cluster and 1 local instance. Both worked for me.
I am going to downgrade this bug since almost all cases are working for me.
If you have a real issue please set up the environment and let me know
Regards,
Bhakti
This is my setup on your machine
./asadmin create-cluster c1
533 ./asadmin create-local-instance --cluster c1 i1
534 ./asadmin start-local-instance i1
535 ./asadmin deploy --target c1 hello-jaxws2.war

Comment by ramapulavarthi [ 25/Oct/10 ]

Changing the target milestone to not determined as the bug was not reproducible
based on the previous investigation by Bhakti.





[GLASSFISH-13175] Service level WebServiceFeature annotations configured on a WebService reference are not passed to the JAX-WS Runtime Created: 27/Aug/10  Updated: 18/Jan/12

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

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

Operating System: All
Platform: Linux


Issuezilla Id: 13,175

 Description   

JAX-WS allows web services features to be configured on WebService reference
when the target is a service. Service level WebServiceFeatures configured on
WebServiceReference are not passed to the JAX-WS Runtime.

ex:
@FooFeature
@WebServiceRef
HelloService hello;

There are no service level features that are in use now. So the priority is low.






[GLASSFISH-8794] handlers.xml file processing Created: 21/Jul/09  Updated: 06/Jan/11

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

Type: Bug Priority: Minor
Reporter: razvan_petrescu Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 8,794
Status Whiteboard:

v3_exclude,V2.1.1exclude


 Description   

When you deploy a WebService and use a handlers.xml file, the namespace is not
processed correctly.
In the handlers.xml file I have this line:
<service-name-pattern xmlns:ns1="urn:test">ns1:*Service</service-name-pattern>

After deploy, the webservices.xml file contains this line:

<service-name-pattern>

{urn:test}

*Service</service-name-pattern>.

Meanwhile, the services are processed correctly:

<wsdl-service xmlns:ns1="urn:test">ns1:TestService</wsdl-service>
<wsdl-port xmlns:ns1="urn:test">ns1:TestPort</wsdl-port>

I have used the same targetNamespace (urn:test) for this WebService, and also in
handlers.xml.

At startup, Glassfish also complains about this error:

[#|2009-07-21T17:45:08.763+0300|SEVERE|sun-appserver9.1|javax.enterprise.system.tools.deployment|_ThreadID=10;_ThreadName=main;Deployment
descriptor file META-INF/webservices.xml in archive
[test.jar].;16;74;cvc-pattern-valid: Value '

{urn:test}

*Service' is not
facet-valid with respect to pattern
'*|([\i-[:]][\c-[:]]?[\i-[:]][\c-[:]]*?' for type
'qname-pattern'.;_RequestID=542a043f-b8df-4730-a7a1-49b68b50aec4;|"DPL8015:
Invalid Deployment Descriptors in Deployment descriptor file
META-INF/webservices.xml in archive [test.jar].
Line 16 Column 74 – cvc-pattern-valid: Value '

{urn:test}

*Service' is not
facet-valid with respect to pattern
'*|([\i-[:]][\c-[:]]?[\i-[:]][\c-[:]]*?' for type 'qname-pattern'."|#]

[#|2009-07-21T17:45:08.781+0300|SEVERE|sun-appserver9.1|javax.enterprise.system.tools.deployment|_ThreadID=10;_ThreadName=main;Deployment
descriptor file META-INF/webservices.xml in archive
[test.jar].;16;74;cvc-type.3.1.3: The value '

{urn:test}

*Service' of element
'service-name-pattern' is not
valid.;_RequestID=542a043f-b8df-4730-a7a1-49b68b50aec4;|"DPL8015: Invalid
Deployment Descriptors in Deployment descriptor file META-INF/webservices.xml in
archive [test.jar].
Line 16 Column 74 – cvc-type.3.1.3: The value '

{urn:test}

*Service' of element
'service-name-pattern' is not valid."|#]

Here is the generated webservice.xml file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<webservices xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://www.ibm.com/webservices/xsd/javaee_web_services_1_2.xsd">
<webservice-description>
<display-name>TestService</display-name>
<webservice-description-name>TestService</webservice-description-name>
<port-component>
<port-component-name>TestBean</port-component-name>
<wsdl-service xmlns:ns1="urn:test">ns1:TestService</wsdl-service>
<wsdl-port xmlns:ns1="urn:test">ns1:TestPort</wsdl-port>
<service-endpoint-interface>test.TestBean</service-endpoint-interface>
<service-impl-bean>
<ejb-link>TestBean</ejb-link>
</service-impl-bean>
<handler-chains>
<handler-chain>
<service-name-pattern>

{urn:test}

*Service</service-name-pattern>
<handler>
<handler-name>TestHandler</handler-name>
<handler-class>test.TestHandler</handler-class>
</handler>
</handler-chain>
</handler-chains>
</port-component>
</webservice-description>
</webservices>



 Comments   
Comment by razvan_petrescu [ 21/Jul/09 ]

Glassfish V3 is miles away of being production ready (with all the stuff already
present in 2.1) so it should be fixed in the following releases of V2 branch.

Comment by Bhakti Mehta [ 02/Oct/09 ]

Added the keyword

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1





[GLASSFISH-8615] service-name-pattern does not work in handlers.xml Created: 30/Jun/09  Updated: 06/Jan/11

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

Type: Bug Priority: Minor
Reporter: razvan_petrescu Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 8,615
Status Whiteboard:

v3_exclude, v2.1.1_exclude


 Description   

I have created a simple WS Handler and installed using handlers.xml. Everything
works fine, until I've tried to restrict a handler chain to a specific service,
when the namespace information is lost. Here is the content of handlers.xml:

<handler-chains>
<handler-chain name="defaultChain">
<service-name-pattern xmlns:ns1="http://test/">
ns1:*Service
</service-name-pattern>
<handler>
<handler-name>WSSecurityHandler</handler-name>
<handler-class>test.WSSecurityHandler</handler-class>
</handler>
</handler-chain>
</handler-chains>

And here is the Webservices.xml I got from GF admin console after deployment:
(notice: <service-name-pattern>

{null}*Service</service-name-pattern>)


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<webservices xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://www.ibm.com/webservices/xsd/javaee_web_services_1_2.xsd">
<webservice-description>
<display-name>TestService</display-name>
<webservice-description-name>TestService</webservice-description-name>
<port-component>
<port-component-name>TestBean</port-component-name>
<wsdl-service xmlns:ns1="http://test/">ns1:TestService</wsdl-service>
<wsdl-port xmlns:ns1="http://test/">ns1:TestPort</wsdl-port>
<service-endpoint-interface>test.TestBean</service-endpoint-interface>
<service-impl-bean>
<ejb-link>TestBean</ejb-link>
</service-impl-bean>
<handler-chains>
<handler-chain>
<service-name-pattern>{null}

*
</service-name-pattern>
<handler>
<handler-name>WSSecurityHandler</handler-name>
<handler-class>test.WSSecurityHandler</handler-class>
</handler>
</handler-chain>
</handler-chains>
</port-component>
</webservice-description>
</webservices>

I've tested the same test case on the previous version of Glassfish and it works
fine.



 Comments   
Comment by razvan_petrescu [ 30/Jun/09 ]

Found something - it works if the handlers.xml file contains this:
<service-name-pattern xmlns:ns1="http://test/">ns1:*Service</service-name-pattern>

instead of

<service-name-pattern xmlns:ns1="http://test/">
ns1:*Service
</service-name-pattern>

Should these newlines matter in an XML file ???

Comment by razvan_petrescu [ 21/Jul/09 ]

Glassfish V3 is miles away of being production ready (with all the stuff already
present in 2.1) so it should be fixed in the following releases of V2 branch.

Comment by razvan_petrescu [ 21/Jul/09 ]

Changed user, because I got no feedback in a month on a sensitive issue

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Bhakti Mehta [ 17/Sep/09 ]

Added keyword

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1





[GLASSFISH-7043] After redeployment I get 403 on basic auth metro ws Created: 15/Jan/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: oaspublic Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,043

 Description   

I redeploy basic auth ws on a 2 node cluster via web gui. The realm is a file
realm. Befor redeployment all works fine, aber deploy 403. I don't see any
errors at log. Pls say what you need to isolate the problem.

Os: win2000, jdk1.6.0.4
Sun Java System Application Server 9.1_02 (build b04-fcs)

regards Dietmar



 Comments   
Comment by Hong Zhang [ 15/Jan/09 ]

Assign to Bhakti as it's a web services application...

Comment by harpreet [ 16/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by oaspublic [ 16/Jan/09 ]

I don't agree to this, because I have this problem at a production critical
system and current my only workaround is restart cluster. If we found a other
good workaround it's ok for me. If we don't find a good workaround I need a
workable solution or a fix at this or a production release!

Comment by oaspublic [ 20/Mar/09 ]

I did some checks and build a case and now the status is:

this problem isn't releated to ws only! I can confirm, that the error always
exists at a web app with file realm when I redeploy a clustered web application.
Restart the cluster solve the problem.

With version:

Sun GlassFish Enterprise Server v2.1 (9.1.1) (build b60e-fcs)

it seems to work like expected

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4063] @Oneway web service operation has text/html response content-type Created: 02/Feb/08  Updated: 06/Jan/11

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

Type: Bug Priority: Minor
Reporter: sauvage Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forum.java.sun.com/thread.jspa?threadID=5257748


Issuezilla Id: 4,063

 Description   

Hi,

It seems a web service operation annotated with @Oneway returns HTTP 202 with
empty content.
But the response content-type is text/html. That is a problem for some clients
(e.g. Perl SOAP::Lite).

And the HTTP response code should be 204.

Regards,

Laurent.



 Comments   
Comment by Bhakti Mehta [ 07/Feb/08 ]

Looking into it

Comment by jitu [ 07/Feb/08 ]

See Basic Profile 1.1's section's 4.7.9 section.

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

So we cannot do much about response code, but probably not send content-type.

Comment by harpreet [ 09/Apr/08 ]

Based on input from Bhakti, assigning issue to next release

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."





[GLASSFISH-3973] Catalog file not being processed Created: 05/Jan/08  Updated: 06/Jan/11

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

Type: Bug Priority: Minor
Reporter: ronak2121 Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,973

 Description   

The jaxws-catalog.xml file is not always processed correctly.

In the first scenario, the user deploys a web service which uses a catalog file
using the Admin Console. Then, when a client accesses the web service through a
method call, JAXWS processes the catalog file and everything runs well.

However, as soon as Glassfish is shutdown and restarted, any accesses to the
web service does not trigger the catalog file to be processed.



 Comments   
Comment by Bhakti Mehta [ 07/Jan/08 ]

Hi,
Please can attach your test source/NB project so we can reproduce it
Thanks,
Bhakti

Comment by harpreet [ 09/Apr/08 ]

Assigning to next release based input by Bhakti

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."





[GLASSFISH-4872] WebService not being resolved when @HttpSessionScope Created: 23/Apr/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: adeanva Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 4,872

 Description   

I have a glassfish (v2ur2) instance with 2 web services.
I've added a MessageHandler to retrieve client username from header.
Once I configure the service as a Secure Service using "Username Authentication
with Symmetric Key" I can no longer hit the service.
I also saw this issue in glassfish v2ur1.
I see traffic in the MessageHandler, but then I get the follow exception:

The log message is null.
java.lang.NullPointerException
at
com.sun.xml.ws.server.AbstractMultiInstanceResolver.prepare(AbstractMultiInstanceResolver.java:78)
at
com.sun.xml.ws.server.AbstractMultiInstanceResolver.create(AbstractMultiInstanceResolver.java:87)
at
com.sun.xml.ws.server.servlet.HttpSessionInstanceResolver.resolve(HttpSessionInstanceResolver.java:70)
at
com.sun.enterprise.webservice.InstanceResolverImpl.resolve(InstanceResolverImpl.java:74)
at
com.sun.enterprise.webservice.InstanceResolverImpl$1.invoke(InstanceResolverImpl.java:112)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
at
com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at
com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at
com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at
com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at
com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
at
com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.JAXWSServlet.doPost(JAXWSServlet.java:176)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)



 Comments   
Comment by adeanva [ 05/May/08 ]

I've done more debugging and I only get this error for my web service when I try
to track session with the @HttpSessionScope.
I can create a web service from a wsdl and it works fine, but if I add the
@HttpSessionScope I get the previous error.
I have used this annotation before with JAX-WS in WebLogic

Comment by kumarjayanti [ 05/May/08 ]

What happens when you remove the MessageHandler. Does it still run into the same
issue ?.

What are the steps to reproduce the problem ?.

Thanks

Comment by kumarjayanti [ 19/Sep/08 ]

Can you try this with latest builds from :
https://sailfin.dev.java.net/downloads/v1-b51.html

And let us know.

Comment by kumarjayanti [ 19/Sep/08 ]

Also try installing Latest Metro 1.3 bits on GlassFish and give it a try.

https://metro.dev.java.net/1.3/

Comment by Bhakti Mehta [ 25/Sep/08 ]

Accepting issue and will fix this after prelude

Comment by jitu [ 25/Sep/08 ]

When I actually checked, I already have a testcase for this in standalone
deployment. Bhakti, you can use this testcase for 109 deployment.

http://fisheye5.cenqua.com/browse/jax-ws-sources/jaxws-unit/testcases/server/http_session_scope

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-6495] Web application web service deployed cluster instance returns invalid WSDl Created: 09/Oct/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: gmpatil Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File ExtractEventService.war    
Issuezilla Id: 6,495

 Description   

Using Sun Java System Application Server 9.1_02 (build b04-fcs)

When Web application containing Web service is deployed to cluster instances,
below issues are encountered.
1) WSDL returned thru "?WSDL" on node instance http port is returned with
invalid port.
Ex:
http://host1.instance1:38080/ExtractEventService/ExtractEventService?wsdl
returns WSDL
which imports XSD's from DAS server and port 8080 where Web application is not
deployed. Even though packaged WSDL imports XSD's using relative path.
<xsd:import namespace="http://docs.oasis-open.org/wsn/b-2"
schemaLocation="http://GPATIL:8080/ExtractEventService/ExtractEventService/__container$publishing$subctx/WEB-INF/wsdl/ExtractEventService/b-2.xsd"/>

This causes Java EE Engine to fail while processing messages as it can not parse
the WSDL.

2) Not all the instances returns the WSDL using the
http://host1.instance1:38080/ExtractEventService/ExtractEventService?wsdl.



 Comments   
Comment by gmpatil [ 09/Oct/08 ]

Created an attachment (id=1946)
Web application. with WS URL /ExtractEventService/ExtractEventService

Comment by Bhakti Mehta [ 10/Oct/08 ]

Looking at this

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-6445] Need to provide better information when user deploys webservices to v3 without installing metro from UC Created: 06/Oct/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: not determined

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

Operating System: All
Platform: All


Attachments: Text File diffs.txt    
Issuezilla Id: 6,445
Status Whiteboard:

gfv3-prelude-excluded


 Description   

Currently if a user deploys to v3 without installing metro from UC he will get a
ClassNotFoundException [1]

I would like to provide better error message to the user asking him to install
metro by running UC client

Filing this bug to keep track of this issue and so I can commit the fix

[1]java.lang.ClassNotFoundException: com.sun.xml.ws.transport.http.servlet.WSServle
tContextListener
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoade
r.java:1509)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContex
t.java:4574)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5
311)

Here is the patch which would fix this problem

Index: src/main/java/org/apache/catalina/core/StandardContext.java
===================================================================
— src/main/java/org/apache/catalina/core/StandardContext.java (revision 23226)

+++ src/main/java/org/apache/catalina/core/StandardContext.java (working copy)
@@ -4578,9 +4578,16 @@
results[i]);
// END PWC 1.2 6310695
} catch (Throwable t) {

  • getServletContext().log
  • (sm.getString("standardContext.applicationListener",
  • listeners[i]), t);
    +
    + if (listeners[i].equals("com.sun.xml.ws.transport.http.servlet.
    WSServletContextListener")) { + getServletContext().log(sm.getString("standardContext.missin gmetro"),t) ; + + }

    else

    { + getServletContext().log + (sm.getString("standardContext.applicationListener", + listeners[i]), t); + }

    +
    ok = false;
    }
    }
    Index: src/main/resources/org/apache/catalina/core/LocalStrings.properties
    ===================================================================

      • src/main/resources/org/apache/catalina/core/LocalStrings.properties (revisio
        n 23226)
        +++ src/main/resources/org/apache/catalina/core/LocalStrings.properties (working
        copy)
        @@ -259,3 +259,5 @@
        standardContext.alternateDocBase.missingPathOrUrlPattern=PWC1417: Missing alter
        nate docbase URL pattern or directory location
        standardContext.startManager.error=PWC1418: Error manager.start()
        standardContext.duplicateListener=PWC1419: The listener " {0}

        " is already config
        ured for this context. The duplicate definition has been ignored.
        +standardContext.missingmetro=PWC1420: This is a webservice based application a
        nd for this Metro needs to be installed...\n Pls run updatecenter client located
        in bin folder to install metro
        +



 Comments   
Comment by Bhakti Mehta [ 06/Oct/08 ]

Updated the title to mention that the CNFE occurs when we try to deploy
webservices based app without installing metro

Comment by jluehe [ 06/Oct/08 ]

Created an attachment (id=1936)
luehe diffs

Comment by jluehe [ 06/Oct/08 ]

Hi Bhakti, your diffs would work, but my preference would be to refactor the
code in web-core's StandardContext.java that is responsible for loading and
instantiating listeners, so we can override it in web-glue's WebModule.java
(which is a subclass of StandardContext.java) and log the warning there.

I was thinking of something along the lines of the attached diffs ("luehe diffs").

Let me know if that would work for you.

Comment by jluehe [ 06/Oct/08 ]

Sending
web/war-util/src/main/resources/com/sun/logging/enterprise/system/container/web/LogStrings.properties
Sending
web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebModule.java
Transmitting file data ...
Committed revision 23238.

Comment by jluehe [ 07/Oct/08 ]

Ported fix to v3_prelude_release branch:

Sending
web/war-util/src/main/resources/com/sun/logging/enterprise/system/container/web/LogStrings.properties
Sending
web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebModule.java
Transmitting file data ...
Committed revision 23246.

At this morning's v3 engineering meeting, it was agreed that this fix should be
considered temporary only.
Post prelude, a "webservices sniffer" would be responsible for intercepting the
deployment of an application exposing webservices (based on the presence of a
webservices.xml deployment descriptor) and abort the deployment if Metro was not
installed.

Reopening this issue and reassigning it to Bhakti.

Comment by jluehe [ 07/Oct/08 ]

...

Comment by Bhakti Mehta [ 08/Oct/08 ]

Accepting bug and making note this is exclude for v3 prelude

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5289] Tester page enabled for services secured with new namespaces Created: 10/Jul/08  Updated: 10/Feb/13

Status: Open
Project: glassfish
Component/s: web_services, web_services_mgmt
Affects Version/s: 9.1peur2
Fix Version/s: not determined

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 5,289

 Description   

This issue is opened as a replacement for wsit issue #922 (
https://wsit.dev.java.net/issues/show_bug.cgi?id=922 ):

If you secure your service with new metro13 namespaces, the Tester page is
enabled for it. It shall be disallowed, same as with metro10 namespaces.



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5173] Resource injection fails in web service on URL specified in web.xml servlet mapping. Created: 17/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: nikolaj_a Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Java Source File FailedInjectionWebService.java    
Issuezilla Id: 5,173

 Description   

It seems that all resource injection fails on a web service implementation class when it is accessed by
the servlet mapping URL. Also, GlassFish automatically creates and alternative URL (why is this?) which
can be found in the admin GUI, where resource injection works perfectly.

Resource injection should work when a web service is called on the URL specified in the web.xml
servlet mapping.

As a workaround, is it possible to somehow change the automatically assigned URL, possibly via
webservices.xml or the like?

See also last post in http://forums.java.net/jive/thread.jspa?threadID=38298

Best regards,
Nikolaj



 Comments   
Comment by nikolaj_a [ 17/Jun/08 ]

Created an attachment (id=1562)
Example source file illustrating the failed resource injection, and a possible workaround.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5156] GF ignores SEI(interface)'s @WebService params. it cause NPE or incorrect configuration Created: 14/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: v2.1.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: kasaihiroyoshi Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File SEI_ann_ignored.WebServiceHandler.java.patch    
Issuezilla Id: 5,156

 Description   

Only wsdlLocation is read. Other SEI(Service Endpoint Interface)'s @WebService
params are ignored.

That causes

  • default values are used, even though user write needed values as SEI's
    @WebService params.
  • In deployment, matching of DD's port-component-name and SEI' @WebService.name
    fail,
  • So, incomplete two webservice registrations are created
  • the incompleteness causes NPE, that user hardly understand reason of it.
  • Here, 'SEI' means interface that is written in impl's
    @WebService.endpointinterface.


 Comments   
Comment by kasaihiroyoshi [ 14/Jun/08 ]

Created an attachment (id=1557)
I wrote fix as a trial, that seems work for me . project: appserv-commons class:com.sun.enterprise.deployment.annotation.handlers.WebServiceHandler method:processAnnotation

Comment by kasaihiroyoshi [ 14/Jun/08 ]

Additionally, wsimport writes many information to SEI(interface, not impl), I
think the problem has large impact.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kasaihiroyoshi [ 27/May/09 ]

I think this issue is relatively major spec violation problem.
It happens in 2.1.1 too. P4 seems low a bit for me.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4158] DEA: MARSHAL exception when trying to return List via webservice Created: 12/Feb/08  Updated: 09/Dec/11

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

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

Operating System: All
Platform: All


Attachments: Java Archive File EnterpriseApplicationTest-ejb.jar     Zip Archive EnterpriseApplicationTest.zip     Zip Archive screenshots.zip     Text File server.log    
Issuezilla Id: 4,158

 Description   

The issue occurs while deploying EJB and WAR file separately. It seems there is
a issue while returning a LIST in a webservice when remote interface is used.( I
am aware that when deployed EJB and WAR separately, the communication is going
to happen through remote interfaces).

Here is the code where the exception was occurring
/*CustomerFacade.java

public void removeAll(List<Customer> customers)
{
for (Customer customer : customers)

{ em.remove(em.merge(customer)); }

}

I have attached the project,server.log file along with some screen shots.



 Comments   
Comment by vamsee_krishna [ 12/Feb/08 ]

Created an attachment (id=1333)
Project demonstrating the issue

Comment by vamsee_krishna [ 12/Feb/08 ]

Created an attachment (id=1334)
server log file

Comment by vamsee_krishna [ 12/Feb/08 ]

Created an attachment (id=1335)
screenshots showing the DB structure,Deployment Scenario

Comment by vamsee_krishna [ 12/Feb/08 ]

Environment:-
JavaEE,MySQL,Hibenate,Facelets-1.1.12
-----------------------------------------------------
More information:-

When an single object is been sent, it works properly. Issue exists only when a
LIST of objects been sent.

Please refer create and removeAll Methods under CustomersFacade.java for better
understanding.

Comment by Bhakti Mehta [ 12/Feb/08 ]

Looking into it

Comment by Bhakti Mehta [ 12/Feb/08 ]

Assigning to Mahesh for evaluation.

Comment by Mahesh Kannan [ 14/Feb/08 ]

Can the submitter of this bug post the .war and .jar files?

Comment by vamsee_krishna [ 14/Feb/08 ]

Created an attachment (id=1337)
jar file of the application

Comment by vamsee_krishna [ 14/Feb/08 ]

war file can not be uploaded as size is 22.3MB.

Mahesh,
Any other areas you prefer to upload the file.

Comment by vamsee_krishna [ 15/Feb/08 ]

Mahesh,

I have uploaded the war file. Please find the link below
http://www.4shared.com/file/37889021/fec86f2a/EnterpriseApplicationTest-war.html

Comment by harpreet [ 21/Mar/08 ]

marking for 9.2

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."





[GLASSFISH-1244] <BT6438701>Tester page doesn't work with Sun WebServer 6.1 Loadbalancer Created: 03/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0pe
Fix Version/s: not determined

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

Operating System: Solaris
Platform: All


Issuezilla Id: 1,244

 Description   

*********READ-ONLY Data from Bugtraq*********************
Description Unable to access to Testser page if it's configured through a loadbalancer. Server busy page appears when access to the Tester pageSTEPS TO REPRODUCE:1. Install AppServers 9PE http://easqelx16.red.iplanet.com:4848 & http://easqelx16.red.iplanet.com:80802. Install WebServer 6.1 Loadblancer http://davis.red.iplanet.com:60603. Configure loadblancer for AppServer 9PE4. Deploy the attached application TestWebJAX-WS205. Launch a browser and access to the application from Loadbalancer http://davis.red.iplanet.com:6060/TestWebJAX-WS20 and http://davis:6060/TestWebJAX-WS20/NewServiceService?wsdlNote: Both url were accessed successfully. Application works with the Loadbalancer6. Access Tester url http://davis:6060/TestWebJAX-WS20/NewServiceService?TesterBUG: Busy Server message appears on the access page Tester page does not work with Sun Webserver Loadbalancer
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to XXXXXX 2006-06-14 18:38:17 GMT
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
http://swsblweb1.central.sun.com:8080/CrPrint?id=6438701
**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by gfbugbridge [ 02/Nov/06 ]

*********READ-ONLY Data from Bugtraq*********************
Description Unable to access to Testser page if it's configured through a loadbalancer. Server busy page appears when access to the Tester page
STEPS TO REPRODUCE:
1. Install AppServers 9PE
http://easqelx16.red.iplanet.com:4848 & http://easqelx16.red.iplanet.com:8080
2. Install WebServer 6.1 Loadblancer
http://davis.red.iplanet.com:6060
3. Configure loadblancer for AppServer 9PE
4. Deploy the attached application TestWebJAX-WS20
5. Launch a browser and access to the application from Loadbalancer
http://davis.red.iplanet.com:6060/TestWebJAX-WS20 and
http://davis:6060/TestWebJAX-WS20/NewServiceService?wsdl
Note:
Both url were accessed successfully.
Application works with the Loadbalancer
6. Access Tester url http://davis:6060/TestWebJAX-WS20/NewServiceService?Tester
BUG:
Busy Server message appears on the access page
Tester page does not work with Sun Webserver Loadbalancer

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to XXXXXX 2006-06-14 18:38:17 GMT

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6438701
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6438701
**********READ-ONLY Data from Bugtraq Ends********

Comment by vijaysr [ 21/Feb/07 ]

reassigning

Comment by vijaysr [ 21/Feb/07 ]

reassigning

Comment by mikeg [ 25/Feb/07 ]

It looks like the logic used by the tester page assumes that the
WebServiceTesterServlet instance sending the test request and the endpoint
servicing the request are in the same VM. This won't generally be the case if
the test request is sent through the LoadBalancer. The usage of the
LoadBalancer here is an edge case considering the fact that the service can
still be tested by sending the test request directly to the AS hosting the
endpoint. Reducing the priority.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-482] Service Endpoint Address and Classes for Web Service Methods overlapping Created: 27/Mar/06  Updated: 15/Oct/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: tomo_ikeda Assignee: mikeg
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 482

 Description   

Hello!
My name is Tomohiro Ikeda.
I'm using GlassFish for Web Service in the web container (not in the EJB
container).
It is very useful and very easy for development and I will continue to use it.
But I found two problems in it.

First problem occurs in case that there are two (or more) Service Implementation
Beans that have the same name in different packages.
For example as below.
<a web module>
`-- WEB-INF
`-- classes

– pack01
`-- Class01 (Service Implementation Bean : pack01.Class01)
`-- pack02
`-- Class01 (Service Implementation Bean : pack02.Class01)
If these Service Implementation Beans have default WebService Annotation
(without "serviceName" value), their Service Endpoint Addresses overlap.
Because default name of the Service Class is simple name of the Service
Implementation Bean + "Service" and Endpoint Address is "http://<hostname[:port]
>/<web module>/<simple name of the Service Class>".
Therefore, the WSDL files generated automatically by the container overlap, and
one is overwritten with the other.
In this case, one Web Service is not available although it is present in Admin
Console page of GlassFish.
And Web Service name in Admin Console is sometime simple name of Service
Implementation Bean and sometime FQDN of one.
Of cource, we can avoid this problem by indicating serviceName in WebService
Annotation such as "pack01.Class01", but I think that it should work without
serviceName value.
Default value of serviceName is decided in JSR-181 and we can not change it, but
I think that Service Endpoint Address should include package information of the
Service Class.
Does it violate any specification ?

Second problem occurs in case that two (or more) Service Implementation Beans in
the same package have method with the same name.
For example as below.
<a web module>
`-- WEB-INF
`-- classes
`-- pack01

– Class01 (Service Implementation Bean : pack01.Class01)
`-- method01(.., ..)
`-- Class02 (Service Implementation Bean : pack01.Class02)
`-- method01()
Classes genarated automatically by the container for the Web Service Methods
overlap, and one is overwritten with the other.
In this case, cryptic exception occurs in the client side at the run time though
source files are successfully compiled.
And we cannot aboid this problem.
A method is unique in a class or interface, and I think that generated classes
for Web Service Methods should include information of the name of Service
Implementation Bean.
Does it violate any specification too?

These problems occur in the server side, and the developers in the client side
cannot know what happened and why does not it work.
If these problems are insoluble, I think that the container should reject
deployment with appropriate messages.

I hope you will take good care of this. Thank you.



 Comments   
Comment by vijaysr [ 27/Mar/06 ]

reassigning ownership

Comment by vijaysr [ 27/Mar/06 ]

started

Comment by vijaysr [ 27/Mar/06 ]

I am changing this as an enhancement to be implemented later. As of now for the
first case, user can use the serviceName attribute. For the second case, user
can use wsgen with customization and package these generated classes as part of
the WAR being deployed.

Comment by vijaysr [ 13/Mar/07 ]

reassigning to mike

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-16939] Warning when using @RunAs annotation on a JAX-RS web service Created: 01/Jul/11  Updated: 01/Aug/12

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

Type: Bug Priority: Minor
Reporter: mmuller Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008


Attachments: File jaxrs-inheritance_warning.war     GZip Archive jaxrs_inheritance_warning.tar.gz    
Tags: jax-rs, warning

 Description   

Annotating a JAX-RS web service class with @RunAs triggers a warning at deployment-time:

[#|2011-07-01T14:11:48.035+0200|WARNING|glassfish3.1|global|_ThreadID=21;_ThreadName=Thread-1;|The annotation symbol inheritance is not supported.
symbol: TYPE
location: class test.Service1

I don't really know if this is the expected behaviour, as this warning does not appear with @DeclareRoles and @RolesAllowed annotations.

The maven project attached contains:

  • An EJB exposed as JAXRS service.
  • A web.xml descriptor, to load Jersey's ServletContainer on startup.
  • A glassfish-ejb-jar.xml descriptor to map roles and define the run-as principal.


 Comments   
Comment by arjan tijms [ 27/Nov/11 ]

I get the same warning in 3.1.1 with @RunAS on a stateless or singleton session bean and on a message driven bean, e.g.:

WARNING: The annotation symbol inheritance is not supported.
 symbol: TYPE
 location: class com.example.RolesTestMDB

WARNING: The annotation symbol inheritance is not supported.
 symbol: TYPE
 location: class com.example.RolesTestStartupSingleton

WARNING: The annotation symbol inheritance is not supported.
 symbol: TYPE
 location: class com.example.RolesTestEJB
Comment by dmitriy.balakin [ 01/Aug/12 ]

GF 3.1.2.2, @Runas + @Singleton/@Steteless - WARNING still appears.

Comment by Hong Zhang [ 01/Aug/12 ]

assign to webservices team for initial evaluation





[GLASSFISH-16141] Updatet from embedded version 3.0.1 to 3.1 causes SEVERE: Exception while invoking class org.glassfish.webservices.WebServicesDeployer prepare method Created: 03/Mar/11  Updated: 06/Apr/12

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

Type: Bug Priority: Minor
Reporter: manuel_b Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: 16 minutes
Time Spent: Not Specified
Original Estimate: 16 minutes
Environment:

Mac OS X 10.6.6, Java version "1.6.0_22", Glassfish 3.1 (groupId: org.glassfish.extras, artifactId: glassfish-embedded-all, version: 3.1)


Attachments: XML File domain_withoutpasswords.xml    
Tags: 3_1-upgrade, 3_1_1-scrubbed, update, upgrade, webservice-api

 Description   

When upgrading the dependency from embedded glassfish from 3.0.1 to 3.1 the WebServiceDeployer is not starting up.

During throwing the real error message another error is happening:

SEVERE: Exception while invoking class org.glassfish.webservices.WebServicesDeployer prepare method
Jan 27, 2011 4:30:30 PM org.glassfish.api.ActionReport failure
SEVERE: Exception while preparing the app
java.util.logging.ErrorManager: 5
java.lang.NullPointerException
at java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:136)
at java.util.ResourceBundle.getObject(ResourceBundle.java:368)
at java.util.ResourceBundle.getString(ResourceBundle.java:334)
...

I am running an embedded glassfish in my TestNG. These get started by maven. I was able to attache a debugger:

  1. start TestNG test (which start internally a embedded glassfish)
    $ mvn -Dmaven.surefire.debug test
  2. wait until it stops and attach the debugger
    $ jdb -attach 5005
  3. Use http://java.net/projects/glassfish/sources/svn/content/tags/3.1/core/kernel/src/main/java/com/sun/enterprise/v3/server/ApplicationLifecycle.java?rev=45380
  4. to know where to set a breakpoint
    > stop at com.sun.enterprise.v3.server.ApplicationLifecycle:412
  5. wait until it stops and show local variables
    > locals
  6. print a stack trace
    > eval prepareException.printStackTrace()

Here is the complete stack trace for the WebServicesDeployer prepare methodexception.
SEVERE: Exception while invoking class org.glassfish.webservices.WebServicesDeployer prepare method
java.lang.RuntimeException
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:192)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:870)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:410)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:193)
at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:142)
at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:135)
at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:132)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
at de.apaxo.semrecsys.test.EJB3Container.startGlassfish(EJB3Container.java:57)
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 org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:73)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:516)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:196)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:126)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:258)
at org.testng.SuiteRunner.run(SuiteRunner.java:221)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:946)
at org.testng.TestNG.runSuitesLocally(TestNG.java:883)
at org.testng.TestNG.run(TestNG.java:814)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74)
at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
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 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Caused by: java.lang.NullPointerException
at org.glassfish.webservices.WsUtil.getWebServerInfoForDAS(WsUtil.java:1548)
at org.glassfish.webservices.WebServicesDeployer.doWebServicesDeployment(WebServicesDeployer.java:618)
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:183)
... 33 more

http://java.net/projects/glassfish/sources/svn/content/tags/3.1/webservices/jsr109-impl/src/main/java/org/glassfish/webservices/WsUtil.java?rev=45380

So the problem seems to be that the networkListeners are empty and the following code which is supposed to fill them is not working correctly:

...
if(this.networkListeners == null) {
List<Integer> adminPorts = new ArrayList<Integer>();

for (org.glassfish.api.container.Adapter subAdapter :
habitat.getAllByContract(org.glassfish.api.container.Adapter.class)) {
if (subAdapter instanceof AdminAdapter)

{ AdminAdapter aa = (AdminAdapter) subAdapter; adminPorts.add(aa.getListenPort()); }

else if (subAdapter instanceof AdminConsoleAdapter)

{ AdminConsoleAdapter aca = (AdminConsoleAdapter) subAdapter; adminPorts.add(aca.getListenPort()); }


}

for (NetworkListener nl : config.getNetworkConfig().getNetworkListeners().getNetworkListener()) {

if(!adminPorts.contains(Integer.valueOf(nl.getPort())))

{ // get rid of admin ports if(networkListeners == null) networkListeners = new ArrayList<NetworkListener>(); networkListeners.add(nl); }


}
}
...



 Comments   
Comment by Bhakti Mehta [ 18/May/11 ]

I will look more into this issue

Comment by Bhakti Mehta [ 15/Jun/11 ]

Please can you give me the exact steps which you take to upgrade so I can reproduce this

Comment by manuel_b [ 15/Jun/11 ]

Hi Bhakti,
unfortunately I can just give you the maven pom entries:

working:
<dependency>
<groupId>org.glassfish.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.0.1</version>
<scope>test</scope>
</dependency>

Not working:
<dependency>
<groupId>org.glassfish.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.1</version>
<scope>test</scope>
</dependency>

I will also attach my domain.xml.

If you have any recommendations I can reconfigure my system and try again.

Comment by manuel_b [ 15/Jun/11 ]

Added domain file for glassfish 3.0.1 which was used when using embedded 3.1.

Comment by manuel_b [ 15/Jun/11 ]

Hi Bhakti,
no I am not in the Glassfish QE team. I am just a student who just finished his master degree and who was using Glassfish.

I am running an own EAR file on glassfish. You can read my thesis and documentation about the application here:

http://manuel.themis02.de/MasterThesisEvalRecommender/trunk/doc/2010-Manuel-Blechschmidt-730786-EvalRecSys.pdf

User: guest
Password: guest

I just registered for JIRA and joined your effort. Thought it could be useful for your if I log my experiences.

Feel free to ignore this request.

Comment by netstart [ 06/Apr/12 ]

I have the same problem





[GLASSFISH-16294] PostConstruct called twice for web service Created: 31/Mar/11  Updated: 14/Feb/13

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

Type: Bug Priority: Minor
Reporter: sennen Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1, Windows Vista


Attachments: Zip Archive postconstructissue.zip    

 Description   

Simple annotated web service with public constructor, private @PostConstruct and @PreDestroy methods, and a single web service method.
For each call to the web service method, I see a new service object created and two calls to the PostConstruct method, e.g.

INFO: WEB0671: Loading application [PostConstructIssue] at [/PostConstructIssue]
INFO: PostConstructIssue was successfully deployed in 959 milliseconds.
INFO: parsing WSDL...

INFO: Generating code...

INFO: Compiling code...

INFO: Invoking wsimport with http://localhost:8080/PostConstructIssue/MyWebServiceService?WSDL
INFO: wsimport successful
INFO: webapp.postconstructissue.MyWebService@d4d7db constructor
INFO: webapp.postconstructissue.MyWebService@d4d7db @PostConstruct init
INFO: webapp.postconstructissue.MyWebService@d4d7db @PostConstruct init
INFO: webapp.postconstructissue.MyWebService@c8d0e constructor
INFO: webapp.postconstructissue.MyWebService@c8d0e @PostConstruct init
INFO: webapp.postconstructissue.MyWebService@c8d0e @PostConstruct init

Example Maven project attached.

Aside from the double-call to the @PostConstruct method, I notice each webservice method call results in a new service object being created. This is different from GlassFish 2.1 behaviour - is it expected, and if so, is the old behaviour configurable?



 Comments   
Comment by dmitriy.balakin [ 28/Dec/12 ]

Glassfish 3.1.2.2, bug is still there.

Comment by Romich [ 14/Feb/13 ]

The same problem occurs even if CDI used and WebService marked with javax.enterprise.context.ApplicationScoped annotation.

It is expected the only bean instance is created for application.

Any news about this issue?

Thanks.





[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-3840]  JAXRPC ClassCastException when deploing as EAR (but works for WAR deploy) Created: 06/Nov/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: galet Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 3,840

 Description   

I have following problem when deploying web application with JAX-RPC web
services as a part of EAR archive. ClassCastException occurs when invoking any
deployed web service. However when deploying web application as a standalone WAR
everything works fine. This strange behavior occurs only when <class-loader
delegate="false"/> is set in sun-web.xml.

Well, it seems that in this configuration there are different class loaders for
SOAP serializers/deserializers and application logic.

There should be a way to create web services in WAR when delegate parameter is
set to "false".

Here is my stack trace:

JAXRPC.TIE.04: Internal Server Error (JAXRPCTIE01: caught exception while
handling request: java.lang.ClassCastException: sample.HelloServiceImpl cannot
be cast to sample.HelloServiceSEI)
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:187)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:108)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:254)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:224)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:117)
at $Proxy30.hello(Unknown Source)

This situation can be created with simple HelloWorld JAX-RPC web service and
calling that service.



 Comments   
Comment by wymgaz [ 09/Nov/09 ]
      • Issue 3840 has been confirmed by votes. ***
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2451] JAX-RPC Message handler broken Created: 19/Feb/07  Updated: 07/Mar/13

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0peur1
Fix Version/s: not determined

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

Operating System: All
Platform: All


Attachments: Zip Archive TestWebService.zip    
Issue Links:
Dependency
depends on JAX_RPC-32 JAX-RPC Message handler broken Open
Issuezilla Id: 2,451

 Description   

Hi,

When I set a JAX-RPC message handler to a web service and call it without Sun's
SOAP API I get the following stack trace:
java.lang.ClassCastException: com.sun.xml.messaging.saaj.soap.impl.TextImpl
at
com.sun.xml.rpc.server.StreamingHandler.getOpcodeForRequestMessage(StreamingHandler.java:628)
at com.sun.enterprise.webservice.WsUtil.getInvMethod(WsUtil.java:943)
at
com.sun.enterprise.webservice.ServletPreHandler.handleRequest(ServletPreHandler.java:55)
at com.sun.xml.rpc.client.HandlerChainImpl.handleRequest(HandlerChainImpl.java:86)
at
com.sun.xml.rpc.server.StreamingHandler.callRequestHandlers(StreamingHandler.java:918)
at
com.sun.xml.rpc.server.StreamingHandler.preHandlingHook(StreamingHandler.java:831)
at com.sun.xml.rpc.server.StreamingHandler.handle(StreamingHandler.java:102)
at
com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(JAXRPCServletDelegate.java:443)
at com.sun.enterprise.webservice.JAXRPCServlet.doPost(JAXRPCServlet.java:50)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:767)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:185)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:653)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:534)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.doTask(ProcessorTask.java:403)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:55)

This happens because com.sun.xml.rpc.server.StreamingHandler wrongly assumes the
first child of SOAP Body is an element but it is text in this case.

Regards,

Laurent.



 Comments   
Comment by vijaysr [ 21/Feb/07 ]

Is it possible to give us a test case ?

Comment by sauvage [ 22/Feb/07 ]

Created an attachment (id=756)
test case

Comment by sauvage [ 22/Feb/07 ]

Use TestWebService/test/Hello-soapui-project.xml SOAPUI project to reproduce the
error.

Comment by sauvage [ 22/Feb/07 ]

This bug is duplicate of JAX-RPC GLASSFISH-32 providing a patch.

Comment by vijaysr [ 27/Feb/07 ]

reassign

Comment by mikeg [ 19/Mar/07 ]
      • Issue 2422 has been marked as a duplicate of this issue. ***
Comment by mikeg [ 19/Mar/07 ]

Bug occurs in JAX-RPC codebase only. Need to fix there and re-integrate
JAX-RPC. The bug is caused by a Text node in the SOAPBody of a request message
to a JAX-RPC endpoint that uses handlers. All three conditions are necessary to
reproduce the bug. The Text node here is written by toolkit other than JAX-WS
RI. (soapui. Lowering the priority. Reassigning to JAX-WS Runtime team.

Comment by vivekp [ 28/Oct/09 ]

Assigning to the right owner.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2889] bad address of WSDL Schema and soap binding while glassfish in NAT network Created: 22/Apr/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: kretes Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,889

 Description   

When machine's ip is some kind of 192.168.0.2 and machine is visible from the
internet under some other public IP due to routing doesn't matter if You connect
to some WSDL using public ip, or local network ip, in wsdl there is always
rerference to '192.168.0.2', which is not accessible from all over the internet.
for example
<xsd:import namespace="http://webservices/"
schemaLocation="http://192.168.0.10:8080/UserWebServiceService/UserWebService/__container$publishing$subctx/META-INF/wsdl/UserWebServiceService_schema1.xsd"/>
</xsd:schema>

and same in soap binding in the end of wsdl
Similiar discussions:
https://glassfish.dev.java.net/servlets/ReadMsg?list=users&msgNo=2739
and
https://glassfish.dev.java.net/servlets/ReadMsg?list=users&msgNo=1801

Workaround : download wsdl file and change manually all entries before using it
in some tool.



 Comments   
Comment by gfbugbridge [ 23/Apr/07 ]

<BT6549057>

Comment by kretes [ 17/May/07 ]

It is fixed in v2b47 ( probably some earlier, but haven't checked ) so I suggest
closing

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-6020] Exception in Tester for Soap 1.2 web service Created: 09/Sep/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: jpospisil Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File scr02.png     Zip Archive WebApplication1.zip    
Issuezilla Id: 6,020

 Description   

If I call web service tester for SOAP 1.2 web service (wsdl attached), Tester's
properly displayed,but when I click on "operation()" button, I get exception in
the browser.Attaching screenshot and zipped web project with web service.



 Comments   
Comment by jpospisil [ 09/Sep/08 ]

Created an attachment (id=1797)
screenshot

Comment by jpospisil [ 09/Sep/08 ]

Created an attachment (id=1798)
zipped web service project

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





Generated at Fri Jul 29 11:47:25 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.