<< Back to previous view

[JAX_WS-1006] [Bug 8770868] jaxws ws-sc webservice invocation failed for wstxioexception:invalid null. Created: 08/Sep/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Closed
Project: jax-ws
Component/s: None
Affects Version/s: None
Fix Version/s: current

Type: Bug Priority: Major
Reporter: linguo Assignee: linguo
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: BugDB-8770868 jaxws ws-sc webservice invocation failed for wstxioexception-invalid null
Participants: linguo

 Description   

Migration of existing WebLogic / Oracle bug: https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=877086

[Bug description]
Invocation of a JAXWS WS-SC webservice from a offserver client failed with " com.ctc.wstx.exc.WstxIOException: Invalid null character in text to output". Below is the detailed soap message and server stacktrace.

[Problems Diagnosis]
The files SAX2DOMWriterEx.java and SAX2DOMWriterExFactory.java have been removed from wls_changes. The dependency on these two files which is in AbstractMessageImpl.java has been removed. The test case for this bug which is in "//depot/dev/src1211/wls/modules/wsee/test/server/src/jaxws/wssp12/wssc200502" can run successfully.

[Conclusion]
There is no need to integrate this fix to jaxws22.

Original fix: http://tamarac.us.oracle.com/describe.php?change=1252452






[GLASSFISH-20658] @WebService and @Stateless not showing endpoint in GlassFish 4.0 admin console Created: 24/Jun/13  Updated: 17/Apr/14

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Antonio Goncalves Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: admin-gui stateless webservice
Participants: Anissa Lam, Antonio Goncalves and Bruno Borges

 Description   

I wrote two very basic SOAP Web Services (https://github.com/agoncal/agoncal-sample-jaxws/tree/master/01-EndPoints) : one using a servlet endpoint and another one using an EJB endpoint :

@WebService
public class HelloServletEndpoint {

    public String saySomethingServlet(String something) {
        return "The HelloServletEndpoint is saying : " + something;
    }
}
@WebService
@Stateless
public class HelloEJBEndpoint {

    public String saySomethingEJB(String something) {
        return "The HelloEJBEndpoint is saying : " + something;
    }
}

I've packaged them in a war file and deployed the war into a GlassFish 4.0 instance (a full profile). When I check the admin console, I can view the servlet endpoint (test it and see the generated WSDL) but it does not work with the EJB endpoint (see the attached image). Both WSDLs are available though on the following URLs :

Looks like this is a bug in the UI



 Comments   
Comment by Bruno Borges [ 05/Feb/14 04:16 AM ]

Hi Antonio,

The reason to have <EJBName> as context-root for the @Stateless @WebService is for the case when they are deployed inside EJB modules in EAR files (Java EE 5), where there's no Web access (and so, no context-root).

I wonder though if there's anything in the specification of Java EE 6 that clarifies how the context-root of the EJB WebService should behave in the case it is deployed inside a single WAR instead of an EJB module.

Which specification should we be looking at? EJB or JAX-WS?





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

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

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

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


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

 Description   

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

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

Maven project attached.



 Comments   
Comment by Lukas Jungmann [ 14/Jan/13 10:49 PM ]

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

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

=> failed with following exceptions:

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

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

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

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

=> everything worked fine

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

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

Comment by Lukas Jungmann [ 15/Jan/13 03:57 PM ]

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





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

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

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

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


File Attachments: File MultEndpntsEAR.ear     Java Source File MultEndpntsWS.java    
Tags: webservice
Participants: Lukas Jungmann and stef_esrf

 Description   

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

Please see attached test case. The endpoint definitions are:

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

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

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

Thanks!



 Comments   
Comment by Lukas Jungmann [ 12/Feb/13 02:13 PM ]

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





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

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

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

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


File Attachments: File UnsecureEAR.ear     Java Source File UnsecureService.java    
Tags: webservice
Participants: Lukas Jungmann and stef_esrf

 Description   

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

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

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

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

Thanks!



 Comments   
Comment by Lukas Jungmann [ 11/Feb/13 11:02 AM ]

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





[GLASSFISH-18807] Whitespace in web service handler chain files should be trimmed Created: 15/Jun/12  Updated: 16/Jun/12  Resolved: 15/Jun/12

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

Type: Bug Priority: Major
Reporter: bland999 Assignee: Lukas Jungmann
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Issue Links:
Related
is related to GLASSFISH-18598 Glassfish 3.1.2 can't find JAX-WS han... Resolved
Tags: webservice handlerchain
Participants: bland999, Lukas Jungmann and Martin Grebac

 Description   

When web services are deployed with handler chains, they may refer in the handler chain file to a particular class which implements the handler, as follows:

<javaee:handler-class>myHandler</javaee:handler-class>

Glassfish 3.1.2, 3.1.1, and 3.1 all fail to trim any white space that might be before and after that name. This results in the following...

<javaee:handler-class>myHandler </javaee:handler-class>

...leading to a runtime exception:

[#|2012-04-03T21:59:11.769-0400|SEVERE|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=16;_ThreadName=Thread-3;|Unable to load handler class myHandler

java.lang.ClassNotFoundException: myHandler

In fact, there is whitespace at the end of the name that is being printed in the logs...

For more information, see:

https://forums.oracle.com/forums/thread.jspa?threadID=2369079&tstart=0

Thanks.



 Comments   
Comment by Martin Grebac [ 15/Jun/12 02:17 PM ]

Lukasi, am I right you already mentioned this issue some time ago?

Comment by Lukas Jungmann [ 15/Jun/12 03:01 PM ]

content of handler-class element must be a string without leading/trailing space(s), as per javaee:string definition in http://java.sun.com/xml/ns/javaee/javaee_5.xsd, and as such it is treated and correctly reports that class "myHandler " is not found

Comment by bland999 [ 16/Jun/12 05:31 AM ]

The cited schema states with respect to javaee:string the following:

"This is a special string datatype that is defined by Java EE as
a base type for defining collapsed strings. When schemas
require trailing/leading space elimination as well as
collapsing the existing whitespace, this base type may be
used."

Those two sentences clarify what the end result should be, but I wonder if it is so clear about WHO should be responsible for that end result. I have seen multiple people independently complaining about this type of error within the Glassfish code going back 5 years. It seems to me that if the code can be enhanced to at least strip away leading and trailing whitespace, that would still be advantageous.

If you don't agree, then AT MINIMUM, it would be greatly useful to simply add QUOTES to the error message that reports the error as follows:

Unable to load handler class "myHandler " <<<<--- clearly show the extra spaces here.

There are other places where Class.forName is being called where the same potentially confusing message is being printed.

Keep in mind that most JAX-WS developers do not know when a javaee:string is being used versus an xsd:string. I thoroughly agree that at the end of the day, the developer is responsible, but with a little bit of helpful code, Glassfish could be so much more clearer in this case.

Thanks for listening. I've been using Glassfish for more than 5 years now, and it is my application server of choice, no question about that. Great job, Glassfish team!

Comment by bland999 [ 16/Jun/12 09:46 AM ]

By the way, in a similar issue from "way back when", it was implied that this type of trimming on a "previous version of Glassfish" used to work...

See http://java.net/jira/browse/GLASSFISH-8615





[GLASSFISH-18068] JAX-WS WebService not deployed at correct endpoint uri Created: 21/Dec/11  Updated: 06/Feb/13  Resolved: 06/Feb/13

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

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

OS X 10.7


File Attachments: Zip Archive BugTest.zip    
Tags: 3_1_2-exclude webservice
Participants: hmeerlo and Lukas Jungmann

 Description   

Hi,

when I create a WebService in a WAR file and try to let it listen on a self-defined endpoint uri it fails to do so. It will say in the log file that is listening on the self-defined uri but in relaity it is not. I define the endpoint-uri in the sun-web.xml file like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
<sun-web-app error-url="">
	<context-root>/BugTest</context-root>
	<servlet>
		<servlet-name>HelloService</servlet-name>
		<webservice-endpoint>
			<port-component-name>HelloService</port-component-name>
			<endpoint-address-uri>HelloService/Hello</endpoint-address-uri>
			<transport-guarantee>CONFIDENTIAL</transport-guarantee>
		</webservice-endpoint>
	</servlet>

	<class-loader delegate="true" />
	<jsp-config>
		<property name="keepgenerated" value="true">
			<description>Keep a copy of the generated servlet class java code.</description>
		</property>
	</jsp-config>
</sun-web-app>

The logging says:

{{
INFO: WS00018: Webservice Endpoint deployed
HelloService listening at address at https://phosphorus.service2media.com:8181/BugTest/HelloService/Hello
INFO: Metro monitoring rootname successfully set to: amx:pp=/mon/server-mon[server],type=WSEndpoint,name=/BugTest-HelloService-Hello
INFO: WEB0671: Loading application [BugTest] at [/BugTest]
INFO: BugTest was successfully deployed in 195 milliseconds.
}}

So it claims to listen at https://phosphorus.service2media.com:8181/BugTest/HelloService/Hello when in reality it listens at https://phosphorus.service2media.com:8181/BugTest/HelloService. So the endpoint-address-uri seems to have no effect here.

I have attached a sample project for this bug.



 Comments   
Comment by Lukas Jungmann [ 06/Feb/13 06:01 PM ]

http://java.net/projects/glassfish/sources/svn/revision/59184
http://java.net/projects/glassfish/sources/svn/revision/59188





[GLASSFISH-17648]  'DAS' dependens on 'http-listeners' when deploying EJB based WebService Created: 07/Nov/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.1_b12
Fix Version/s: 3.1.2_b10

Type: Improvement Priority: Major
Reporter: bthalmayr Assignee: Bhakti Mehta
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 6, Java HotSpot(1.7), GF 3.1.1 build12


Tags: 3_1_2-review EJB WebService deployment
Participants: Bhakti Mehta and bthalmayr

 Description   

As I considered the 'DAS' as a 'configuration tool' only I removed the http-listeners ..., but this seems this makes it impossible to deploy Web-Services as EJBs anymore.

During deployment I get the following exception

[#|2011-10-24T13:11:21.328+0200|SEVERE|glassfish3.1.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=52;_ThreadName=Thread-2;|Exception while preparing the app
java.lang.NullPointerException
at org.glassfish.webservices.WsUtil.getWebServerInfoForDAS(WsUtil.java:1548)
at org.glassfish.webservices.WebServicesDeployer.doWebServicesDeployment(WebServicesDeployer.java:619)
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:184)



 Comments   
Comment by Bhakti Mehta [ 14/Nov/11 08:04 PM ]

Committed svn rev Revision: 50825

Please can you try with nov 15 nightly from here http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/nightly/ or 3.1.2 b10 promoted build





[GLASSFISH-17418] Error Deploying: Exception while invoking class org.glassfish.webservices.WebServicesApplication start method java.lang.NullPointerException Created: 13/Oct/11  Updated: 02/Dec/11  Resolved: 16/Nov/11

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

Type: Bug Priority: Major
Reporter: mariohmol Assignee: Lukas Jungmann
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux 2.6.26-2-amd64 #1 SMP x86_64 GNU/Linux
GlassFish Server Open Source Edition 3.2-SNAPSHOT (build 1)


File Attachments: Zip Archive teste.zip    
Tags: 3_1_2-exclude 3_1_2-review deploy deployment ear webservice
Participants: Bhakti Mehta, Hong Zhang, Lukas Jungmann and mariohmol

 Description   

I`m developing using Netbeans 7.0.1 a EAR application.

At localhost it works perfectly:

  • GlassFish Server Open Source Edition 3.1.1 (build 12)
  • 2.6.32-34-generic #77-Ubuntu SMP i686 GNU/Linux.

But in a production enviromment (see more in this ticket) I get a error deploying using command line or at gui asadmin.

The stacktrace is above, please, any help will be appreciated.

Exception while invoking class org.glassfish.webservices.WebServicesApplication start method java.lang.NullPointerException at com.sun.enterprise.v3.services.impl.GrizzlyService.registerEndpoint(GrizzlyService.java:598) at com.sun.enterprise.v3.services.impl.GrizzlyService.registerEndpoint(GrizzlyService.java:576) at com.sun.enterprise.v3.services.impl.GrizzlyService.registerEndpoint(GrizzlyService.java:558) at com.sun.enterprise.v3.services.impl.GrizzlyService.registerEndpoint(GrizzlyService.java:535) at org.glassfish.webservices.WebServicesApplication.start(WebServicesApplication.java:133) at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:294) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:462) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:380) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:455) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) 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:636)



 Comments   
Comment by Hong Zhang [ 13/Oct/11 02:16 PM ]

assign to webservices team for initial evaluation

Comment by Bhakti Mehta [ 14/Oct/11 10:37 PM ]

Please can you attach your application/NB project so we can debug more

Comment by mariohmol [ 16/Oct/11 04:07 PM ]

This same project running using ANT as a EAR project in Netbeans, was working, i have just retested but it's NOT works!

If i take this same code and put into a Maven EAR project, this erros occurs.

Its very easy to reproduce, create a new MAVEN EAR project and a WebService EJB.

I'm attaching a zip file with the project if you cant reproduce.

When a deploy i'm using a virtual server, but i have tested without but the error persists.

Regards,

Comment by mariohmol [ 22/Oct/11 10:37 AM ]

Hy,

I confused myself, this problem occurs in ANT or MAVEN project.

I was using 3.2 because it has a bug in 3.1.1 (http://java.net/jira/browse/GLASSFISH-16223) but now it is already fixed.

So now I'm using latest GF 3.1.1 to production site and everything is working, so its really a bug on 3.2.

When this bug get fixed please annouce here because I will get 3.2 again to test it.

Regards,

Comment by Lukas Jungmann [ 16/Nov/11 09:32 PM ]

Hi,

I tried to reproduce the problem in 3.1.2 branch as well as in trunk and I cannot reproduce it (I tried using asadmin command, GF admin console and autodeploy facility). It seems that this issue has been already fixed somehow.

Feel free to reopen this issue, if you can reproduce this with some latest GF build, ie nightly from: http://dlc.sun.com.edgesuite.net/glassfish/4.0/nightly/ and also attach server log to this issue, please. Thanks!





[GLASSFISH-17224] CDATA data no longer being parsed in newest metro version (2.1.1) Created: 23/Aug/11  Updated: 29/Aug/12  Resolved: 28/Aug/12

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

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

Windows 7, Java jdk1.6.0_26 (64 bit)


File Attachments: Zip Archive metrocdatabug.zip    
Tags: webservice metro woodstox incomplete
Participants: BasVandenBroek, Bhakti Mehta and Martin Grebac

 Description   

We recently upgraded to Metro 2.1.1 from 2.1. Included is a new version of the Woodstox library (StAX parser), 4.1.1 instead of 3.2.1 (see http://java.net/jira/browse/GLASSFISH-16748), this could have something to do with it. In this version we no longer receive our CDATA-surrounded data in the response when calling a webservice. Using a proxy we do see the data actually being sent by the webservice. This problem did not occur in version 2.1.



 Comments   
Comment by Bhakti Mehta [ 12/Oct/11 10:25 PM ]

Assigning to Martin G for more input

Comment by Martin Grebac [ 19/Oct/11 09:24 AM ]

Hi, please attach some reproducible testcase or provide steps to reproduce your issue. Thanks.

Comment by Martin Grebac [ 08/Nov/11 05:22 PM ]

Please reopen with more input. Thanks.

Comment by BasVandenBroek [ 09/Aug/12 12:21 PM ]

Last year I couldn't remember how I reproduced this issue but now I ran into problems again after we updated our Metro library. I have made a testproject this time and am now including it.

I did not include webservices-rt.jar itself due to the size. If you run this project you can include this yourself in the lib folder and fix the .classpath. The test succeeds when using Metro 2.1.0 and fails with Metro 2.1.1 and later. I used Metro 2.2.0-1 as the latest version.

This small project starts a Jetty server which serves as a webservice, it just returns a hardcoded string since I could not find a public webservice that actually uses CDATA encoding and the webservice I reproduced this with is an internal one. This webservice is called and will print a string when text was found and when cdata encoded text was found.

Instructions:
Run the main method in TestCdata.java. See XMLTestStreamingHandler for text that should be printed when test succeeds. See MyHandler for the response that is being sent.

Comment by BasVandenBroek [ 13/Aug/12 11:35 AM ]

I have found something that may be related to this issue at http://ws.apache.org/axiom/userguide/ch04.html#d5e353 (see "Preserving CDATA sections during parsing"), however I was unable to fix the issue with the proposed solution in there (adding a properties file with a specific override).

I did see a StAXParserConfiguration.PRESERVE_CDATA_SECTIONS and StAXParserConfiguration.NON_COALESCING option but I have no idea how to apply this to Metro.

Comment by Martin Grebac [ 28/Aug/12 11:29 AM ]

This was found and fixed in a separate issue - metro 2.2.1 already has the fix and 4.0 codelines have the fix as well.

Comment by Martin Grebac [ 28/Aug/12 11:31 AM ]

reopening to close with proper status

Comment by BasVandenBroek [ 29/Aug/12 12:54 PM ]

Thanks, I ran my testproject on metro 2.2.1 which came out 7 days after my latest addition, it was indeed fixed in this version!





[GLASSFISH-16455] Problem using https webservice client with mutual authentication Created: 26/Apr/11  Updated: 08/Nov/11  Resolved: 08/Nov/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 3.1.1, 4.0

Type: Bug Priority: Major
Reporter: mathcunha Assignee: kumarjayanti
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Red Hat Linux 2.6.18-92.el5 x86_64 x86_64 x86_64 GNU/Linux


Tags: keystore webservice truststore masterpassword 3_1_1-exclude 3_1-next
Participants: kumarjayanti, mathcunha and Tim Quinn

 Description   

Scenario:
Cluster with two instances, one running on a local-node (INST_CLU_LOCAL) and another running on a remote-node (INST_CLU_REMOTE).

Issue:
I have a cluster that run a webservice client that consumes a service that requires mutual authentication. Everything works fine when the request starts from INST_CLU_LOCAL, but when the client starts from INST_CLU_REMOTE the follow error is trown
([#|2011-04-26T10:14:52.807-0300|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=146;_ThreadName=Thread-2;|AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at br.inf.portalfiscal.www.cte.wsdl.CTeDistribuicaoRFB.CTeDistribuicaoRFBSoapStub.cteDistribuicao(CTeDistribuicaoRFBSoapStub.java:179)
at br.gov.ce.sefaz.cte.facade.CTeFacade.cteDistribuicao(CTeFacade.java:62)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.cteDistribuicao(RecuperarCTEReceitaTimer.java:146)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.timeout(RecuperarCTEReceitaTimer.java:89)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4033)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1835)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2708)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

{http://xml.apache.org/axis/}hostname:sd2awj12.sefazce.corp

javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:154)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at br.inf.portalfiscal.www.cte.wsdl.CTeDistribuicaoRFB.CTeDistribuicaoRFBSoapStub.cteDistribuicao(CTeDistribuicaoRFBSoapStub.java:179)
at br.gov.ce.sefaz.cte.facade.CTeFacade.cteDistribuicao(CTeFacade.java:62)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.cteDistribuicao(RecuperarCTEReceitaTimer.java:146)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.timeout(RecuperarCTEReceitaTimer.java:89)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4033)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1835)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2708)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.Fut|#]

[#|2011-04-26T10:14:52.808-0300|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=146;_ThreadName=Thread-2;|ureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)
... 42 more

#])

I think that is a keystore password issue because I have changed the masterpassword, but I used --savemasterpassword and can manage my cluster trought the admin_gui.



 Comments   
Comment by kumarjayanti [ 18/May/11 07:32 PM ]

Not a 3.1.1 blocker. It is not clear that it is a GlassFish or a Metro WebServices problem. The user is using Apache AXIS webservice library and the SSL handshake error has Apache Axis calls at the bottom of the stack trace

Caused by: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)

Comment by mathcunha [ 21/May/11 06:19 AM ]

Hi,

I also figured out that the domain JDK was 1.6_14 and remote jdk was 1.6_21, and to make it works I had to enable the flag java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "true");. After that the problem was gone.

Is it a bug?!

Thank you

Comment by Tim Quinn [ 21/May/11 09:24 AM ]

If you have not already found it, please read through this article:

http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html

which contains abundant information about this SSL handshaking issue.

GlassFish 3.1 and later are supported only with Java 1.6.0_22 or later for exactly this reason.

Comment by kumarjayanti [ 22/May/11 05:17 AM ]

http://weblogs.java.net/blog/kumarjayanti/archive/2010/11/18/ssl-renegotiation-issue-fixed-jdk16022?force=924

marking issue fixed.





[EMBEDDED_GLASSFISH-128] Unsupported deployment descriptors elements Created: 13/Apr/11  Updated: 14/Apr/11

Status: Open
Project: embedded-glassfish
Component/s: API
Affects Version/s: 3.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dmatej Assignee: Bhavanishankar
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: embedded webservice ejb glassfish-ejb-jar sun-ajb-jar endpoint unsupported deployment descriptors element
Participants: Bhavanishankar and dmatej

 Description   

In Junit integration test I'm trying to deploy an EAR application with one EJB JAR module onto embedded glassfish instance. In the module is sun-ejb-jar.xml for SGES2_1_1, but the "endpoint-address-uri" is ignored and the webservice is listening in another context. So I created the glassfish-ejb-jar.xml with the same settings - but it does not work either.

Apr 13, 2011 2:42:49 PM com.sun.enterprise.deployment.archivist.Archivist readRuntimeDeploymentDescriptor
WARNING: DPL8027: Ignore META-INF/sun-ejb-jar.xml in archive .../ear/target/glassfish/instanceroot/applications/my-1.1.0-SNAPSHOT/my-ejb_jar/, as GlassFish counterpart runtime xml META-INF/glassfish-ejb-jar.xml is present in the same archive.
Apr 13, 2011 2:42:49 PM com.sun.enterprise.deployment.node.DeploymentDescriptorNode setElementValue
WARNING: DPL8007: Unsupported deployment descriptors element debugging-enabled value true
Apr 13, 2011 2:42:49 PM com.sun.enterprise.deployment.node.runtime.WebServiceEndpointRuntimeNode setElementValue
SEVERE: DPL5041:Unknown port-component-name MyWS port, all sub elements will be ignored"
Apr 13, 2011 2:42:49 PM com.sun.enterprise.deployment.node.DeploymentDescriptorNode setElementValue
WARNING: DPL8007: Unsupported deployment descriptors element endpoint-address-uri value /webservice/MyWS
Apr 13, 2011 2:42:49 PM com.sun.enterprise.deployment.node.DeploymentDescriptorNode setElementValue
WARNING: DPL8007: Unsupported deployment descriptors element auth-method value BASIC
Apr 13, 2011 2:42:49 PM com.sun.enterprise.deployment.node.DeploymentDescriptorNode setElementValue
WARNING: DPL8007: Unsupported deployment descriptors element transport-guarantee value NONE

....

INFO: WS00019: EJB Endpoint deployed
my-1.1.0-SNAPSHOT listening at address at http://mymachine:8080/MyWS/MyWSBean



 Comments   
Comment by dmatej [ 14/Apr/11 10:32 AM ]

Forget it ... maybe ...

It was my fault - the problem was in port-component-name - if it is incorrect, I can see these tragic messages - I have only one desire - could these messages be more descriptive? It took nearly whole day to find where the problem is ... At first I thought that some settings are not supported and so I cannot use embedded glassfish at all.
Finally I made it work perfectly as I wanted.





[AGROSENSE-57] Attentionmodule CLM: create webservice getVersie Created: 23/Jun/11  Updated: 04/Sep/13  Resolved: 09/Jan/12

Status: Closed
Project: agrosense
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Critical
Reporter: Tom Verhage Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags: attention webservice
Participants: Tom Verhage

 Description   

Create a webservice that returns the date of the latest update






Generated at Fri Apr 25 03:01:21 UTC 2014 using JIRA 4.0.2#472.