May 2009 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Commented: (JBWS-670) Provide JMS transport for JAX-WS client

by Wojciech Oczkowski (JIRA)

[ https://jira.jboss.org/jira/browse/JBWS-670?page=com.atlassian.jira.plugi... ] Wojciech Oczkowski commented on JBWS-670: ----------------------------------------- anyway, at least timeout value and connection factory name shouldn't be hardcoded. > Provide JMS transport for JAX-WS client > --------------------------------------- > > Key: JBWS-670 > URL: https://jira.jboss.org/jira/browse/JBWS-670 > Project: JBoss Web Services > Issue Type: Task > Security Level: Public(Everyone can see) > Components: jbossws-native > Reporter: Thomas Diesler > > Currently, the client will have to use the JMS API directly > InitialContext context = new InitialContext(); > QueueConnectionFactory connectionFactory = (QueueConnectionFactory)context.lookup("ConnectionFactory"); > Queue reqQueue = (Queue)context.lookup("queue/RequestQueue"); > Queue resQueue = (Queue)context.lookup("queue/ResponseQueue"); > QueueConnection con = connectionFactory.createQueueConnection(); > QueueSession session = con.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); > QueueReceiver receiver = session.createReceiver(resQueue); > ResponseListener responseListener = new ResponseListener(); > receiver.setMessageListener(responseListener); > con.start(); > TextMessage message = session.createTextMessage(reqMessage); > message.setJMSReplyTo(resQueue); > waitForResponse = true; > > QueueSender sender = session.createSender(reqQueue); > sender.send(message); > sender.close(); > int timeout = 5000; > while (waitForResponse && timeout > 0) > { > Thread.sleep(100); > timeout -= 100; > } > assertNotNull("Expected response message", responseListener.resMessage); > assertEquals(DOMUtils.parse(resMessage), DOMUtils.parse(responseListener.resMessage)); > con.stop(); > session.close(); > con.close(); > Instead, the client should use the standard JAX-WS API to consume a wsdl that defines the jms binding -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-1878) ConcurrentModificationException in JAXWS Handler when requests hit JBoss during application deployment

by Wojciech Kudla (JIRA)

ConcurrentModificationException in JAXWS Handler when requests hit JBoss during application deployment ------------------------------------------------------------------------------------------------------ Key: JBWS-1878 URL: http://jira.jboss.com/jira/browse/JBWS-1878 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-jaxws Affects Versions: jbossws-2.0.1 Environment: AIX 5.3 ppc64, IBM JVM 9 (1.5.0), JBoss 4.2.1.GA with JBossWS 2.0.1.GA Reporter: Wojciech Kudla Priority: Critical When SOAP requests hit JBoss during application deployment they are somewhat queued and get processed just after the application starts. Everything works fine if the are only several requests. If there are more (like 30 or above) before the application starts, HandlerResolverImpl causes ConcurrentModificationException at line 22 (getHandlerChain()). This exception does not cause the application to stop working, but results in a very strange behaviour, namely: every request goes only through JAXWS Handler twice (on inbound and outbound traffic) but does not hit service implementation (in my case - EJB3 SLSB). The only clue for me to resolve this problem was to stick to the ConcurrentModificationException and its stacktrace. Going down this path I decided to modify some code in class org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS. I synchronized a block of code responsible for initiating handler chains, so the modified method looks like this: public boolean callRequestHandlerChain(ServerEndpointMetaData sepMetaData, HandlerType type) { log.debug("callRequestHandlerChain: " + type); // Initialize the handler chain if (isInitialized() == false) { synchronized(resolver) { resolver.initHandlerChain(sepMetaData, HandlerType.PRE, true); resolver.initHandlerChain(sepMetaData, HandlerType.ENDPOINT, true); resolver.initHandlerChain(sepMetaData, HandlerType.POST, true); setInitialized(true); } } HandlerChainExecutor executor = createExecutor(sepMetaData, type); MessageContext msgContext = (MessageContext)MessageContextAssociation.peekMessageContext(); return executor.handleMessage(msgContext); } I tried to do synchronized(this) at the beginning but it very quickly resulted in unstable AS behaviour and stopping JVM with a core dump in the end (SIC!). Since we are talking about serious production deployment in 5 days (servicing ca. 5000 SOAP requests per hour) , I decided to incorporate my fix into the environment, but I am not completely sure wheter my fix imposes any performance pitfalls. If you find a better idea to solve this problem, please be quick to publish a solution :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
5
0 / 0

[JBoss JIRA] Commented: (JBWS-2615) JBoss does't unload web services classes

by Jeff Gordon (JIRA)

[ https://jira.jboss.org/jira/browse/JBWS-2615?page=com.atlassian.jira.plug... ] Jeff Gordon commented on JBWS-2615: ----------------------------------- I hate to throw in a "me too" comment, but I'm at the beginning stages of troubleshooting something similar so I thought I would comment. I've got an application on JBoss 5.0.1 with 2 sets of deployed web services (a handful of web methods each) that gets hit in our performance testing from another app server and 2 desktop applications (1 using JAX-WS (Sun Metro) on Java 1.5, and 1 using Java 1.6 native implementation). Each web service has a DTO object (Lists of strings mostly with additional Strings and ints in class) and a few Strings as the web service parameters. These all connect to EJB3 stateless session beans along with servlets and timed classes. What we are seeing is that after about 8-10 hours of use the application starts degrading to the point you wouldn't want to use it and at around 20 hours into the test the response time from any call (web service, servlet, or ui) is so slow it would be unusable in a deployed scenario. Anywhere from 1-3 hours later we start getting heap out of memory errors. Using jhat we see that byte arrays and strings make up the bulk of what's in memory (hundreds of thousands of each) and most of them are owned by the generated "ws" classes. I'm not trying to point any fingers, I just found this issue while searching for some answers and haven't attempted much to resolve the issue except for adding some additional gc parameters. The test was running with: -Xms256m -Xmx512m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC I've modified it for troubleshooting to be: -Xms256m -Xmx1024m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintTenuringDistribution -XX:+TraceClassLoading At this point I'm leaning toward some of the web service internals not getting cleaned up fast enough as new ones are being made (sorry I can't provide more heap information on this, I'm working on a vanilla method of replication), and I was looking through the issue list to see if there was a newer version of web services I could stick in the app server to try and mitigate the issue. > JBoss does't unload web services classes > ---------------------------------------- > > Key: JBWS-2615 > URL: https://jira.jboss.org/jira/browse/JBWS-2615 > Project: JBoss Web Services > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Windows 2003 Server, JBoss 5.0.0.GA, Java 1.6.0_12. > Reporter: Edson Goncalez > Priority: Critical > Attachments: generated_source_classes.zip, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, screenshot-4.jpg > > > We have an application that comunicate with a webservice (Federal Government of Brazil) constantly, step by 5 or 10 seconds. > We have created web service consumer classes by using the following command point to the WSDL file: > wsconsume -k -p br.com.compliancefiscal.nfe.ejb.sefaz.ws.nfestatusservico -v NfeStatusServico.wsdl > This tool, was generated this classes: > NfeStatusServico.java > NfeStatusServico_Service.java > NfeStatusServicoNF.java > NfeStatusServicoNFResponse.java > NfeStatusServicoSoap.java > ObjectFactory.java > package-info.java > The problem is. When running... every call this webservice generate a new loadclass. Viewing in the JConsole tool, we can note that whe app starts it have aproximatelly 15000 classes loaded, and afeter 10 hours running we can se that the jvm has increased up to 70000 classes loaded, and only 252 classes unloaded. > I have the screenshot that show this. > What can occours to causing this BIG load classes for same class ? > PS: The app does not run any other service. It just start a method that connect to the specified webservice and return a String info. A TimerService trigger start the process steb by 5 seconds. > Thanks. > Edson Gonçalez. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWS-2649) SOAPMessage implementation bug

by Marcos Prado (JIRA)

SOAPMessage implementation bug ------------------------------ Key: JBWS-2649 URL: https://jira.jboss.org/jira/browse/JBWS-2649 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.0.5 Environment: JBoss 5.0.1.GA compiled with JDK1.6+Java 6+Windows XP SP2 Reporter: Marcos Prado Priority: Blocker Relating to JBWS-1439 issue, I've found the root of the problem: When you get the exception mentioned: java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424) at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:83) at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:161) I found that the jbossws-native-saaj.jar library has an OVERWRITTEN class javax.xml.soap.SOAPMessage which has overwritten (and not overrided) the method setProperty(): public void setProperty(String property, Object value) throws SOAPException { properties.put(property, value); } This class is an ABSTRACT class and the specification clearly indicates: setProperty must be overridden by ALL SUBCLASSES of SOAPMessage. All the javax.xml.soap stuff has been included in the runtime library (rt.jar) in jre 1.6 so, Jboss gives priority to this class and the original one has the next code (as an abstract class) instead of the jbossws-native-saaj.jar one: public void setProperty(String s, Object obj) throws SOAPException { throw new UnsupportedOperationException("setProperty must be overridden by all subclasses of SOAPMessage"); } There is an implementation of SOAPMessage in /client/jbossws-native-core.jar, called org.jboss.ws.core.soap.SOAPMessageImpl which extends the SOAPMessage abstract class but, in this case, the rt.jar is the one that has been loaded in the classpath. This implementation just calls the setProperty() method from his parent... but the parent code is throwing the UnsupporteOperationException!!! As the specification indicates, the method setProperty that has been overwritten in the jbossws-native-saaj.jar, SOAPMessage class must be in the implementation (subclass), not in the abstract class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-2634) Investigate whether support for @EJB annotations is required for WS artifacts too

by Richard Opalka (JIRA)

Investigate whether support for @EJB annotations is required for WS artifacts too --------------------------------------------------------------------------------- Key: JBWS-2634 URL: https://jira.jboss.org/jira/browse/JBWS-2634 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Richard Opalka Assignee: Richard Opalka Fix For: jbossws-native-3.1.2, jbossws-native-3.2.0 Jaikiran wrote: Section EE.5.2.3 (Annotations and Injection) has a table EE.5-1 which lists the component classes supporting injection. It lists JAX-WS service endpoints handlers as one of those. From my understanding (i am not an expert on this :) ), the WebService endpoint need not always be marked as @Stateless (i.e. it's optional). So i guess we would need to support injection in POJO webservice endpoints. On a related note, the user here does mention that this support is available in other application servers http://www.jboss.org/index.html?module=bb&op=viewtopic&t=153488&start=10#... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
8
0 / 0

[JBoss JIRA] Created: (JBWS-2631) Fix resource injection in JAX-WS handlers associated with EJB3 endpoints

by Richard Opalka (JIRA)

Fix resource injection in JAX-WS handlers associated with EJB3 endpoints ------------------------------------------------------------------------ Key: JBWS-2631 URL: https://jira.jboss.org/jira/browse/JBWS-2631 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.1 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: jbossws-native-3.1.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-2643) Create jbossws-native-3.1.2 errata

by Alessio Soldano (JIRA)

Create jbossws-native-3.1.2 errata ---------------------------------- Key: JBWS-2643 URL: https://jira.jboss.org/jira/browse/JBWS-2643 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: productization Reporter: Alessio Soldano Fix For: jbossws-native-3.1.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBWS-2644) Pass JavaEE5 CTS against AS 5.0.1.GA

by Alessio Soldano (JIRA)

Pass JavaEE5 CTS against AS 5.0.1.GA ------------------------------------ Key: JBWS-2644 URL: https://jira.jboss.org/jira/browse/JBWS-2644 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Components: productization Reporter: Alessio Soldano Fix For: jbossws-native-3.1.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBWS-2523) Add support for system environment variables in {EXT} or {CLASS} comment

by Magesh Kumar B (JIRA)

Add support for system environment variables in {EXT} or {CLASS} comment ------------------------------------------------------------------------ Key: JBWS-2523 URL: https://jira.jboss.org/jira/browse/JBWS-2523 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: jbossws-native, ws-security Affects Versions: jbossws-native-3.0.5 Reporter: Magesh Kumar B Priority: Minor It would be productive from a development perspective if environment variables like %JBOSS_HOME% or $JBOSS_HOME is supported in the {EXT} or {CLASS} commands where a path to the external password file is specified. For e.g., <jboss-ws-security xmlns="http://www.jboss.com/ws-security/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/ws-security/config http://www.jboss.com/ws-security/schema/jboss-ws-security_1_0.xsd"> <trust-store-file>WEB-INF/wsse.truststore</trust-store-file> <trust-store-password>{CLASS}org.jboss.security.plugins.FilePassword:$JBOSS_HOME/server/default/conf/keystore.password</trust-store-password> ... </jboss-ws-security> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (JBWS-2618) Update to xmlsec 1.4.2

by Alessio Soldano (JIRA)

Update to xmlsec 1.4.2 ---------------------- Key: JBWS-2618 URL: https://jira.jboss.org/jira/browse/JBWS-2618 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Alessio Soldano Fix For: jbossws-native-3.2.0 While both the AS trunk and the CXF stack reference ver.1.4.2, the Native is still at 1.3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
2
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues May 2009