September 2016 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-4029) Resolving inner xsd with absolute path using includes

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-4029?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-4029: ------------------------------ I'll reject this as we already discussed in the email and found a solution for this issue. {quote} Did you try with <system systemId="http://www.wsdlgetproblem.org/xsd/test/content/includedcontent_a.xsd" uri="classpath:/schema/content/includedcontent_a.xsd"/> ? Change include like <include schemaLocation="http://www.wsdlgetproblem.org/xsd/test/content/includedcontent_b.xsd"/> I mentioned in previous email is changing this element in content.xsd ? There is already catalog configuration should work for this : <rewriteSystem systemIdStartString="http://www.wsdlgetproblem.org/xsd/test/content/" rewritePrefix="classpath:/schema/content/" />. {quote} > Resolving inner xsd with absolute path using includes > ------------------------------------------------------ > > Key: JBWS-4029 > URL: https://issues.jboss.org/browse/JBWS-4029 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: Viral Gohel > Attachments: xsd_catalog_resolving_with_catalog.zip > > > CXF-6234 fixes the writing a new document and replaces public system id’s with class path id’s. However, before doing so, it checks whether the URL to rewrite is indeed in the set of resolved URL’s and schema’s. This set is not resolved correctly. > It seems that the method WSDLGetUtils#getAndSaveRelativeSchemaLocationIfCatalogResolved is the culprit. It all depends on how the ‘doneSchemas’ hashmap is ordered. By some java source code investigation we found out how the hashing mechanism (and thus the sorting) in the ConcurrentHashMap works. This is how we devised the replicator. It uses such file names and URLs that the keys in the map are sorted in such a way that the problem occurs. > Expected behavior when querying with the following URL: http://localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.o..., > <schema elementFormDefault="qualified" targetNamespace="http://www.wsdlgetproblem.org/xsd/test/content" version="1.0.0"><include schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/xsd/..."/><include schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/xsd/..."/></schema> > But.. I do get: > <schema elementFormDefault="qualified" targetNamespace="http://www.wsdlgetproblem.org/xsd/test/content" version="1.0.0"><include schemaLocation="includedcontent_a.xsd"/><include schemaLocation="includedcontent_b.xsd"/></schema> > * The trick in the reproducer is to find such filenames that they line up in a certain order in the ConcurrentHashMap. Most of the XSD/WSDL projects work, although there are far too many entries on the doneSchema's (as shown in the screenshot). > To make the reproducer we tried to figure out which orders are correct and which not. Next we looked up the source of ConcurrentHashMap, checked its key hashing mechanism and constructed the path/file names of the XSD in such a way that they are sorted in the problematic order. It's not easy to trigger the right conditions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4030) Remove unsupported 'start with ssl' command

by Biljana Kramer (JIRA)

Biljana Kramer created JBWS-4030: ------------------------------------ Summary: Remove unsupported 'start with ssl' command Key: JBWS-4030 URL: https://issues.jboss.org/browse/JBWS-4030 Project: JBoss Web Services Issue Type: Enhancement Reporter: Biljana Kramer Priority: Minor When trying to start Apache 2.4 instance using startssl a message is shown: *********************************** java.lang.Exception: Operation START_SSL failed. Exit code: [2] , Output : [The startssl option is no longer supported. Please edit httpd.conf to include the SSL configuration settings and then use apachectl start. *********************************** This command should be removed -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4029) Resolving inner xsd with absolute path using includes

by Viral Gohel (JIRA)

Viral Gohel created JBWS-4029: --------------------------------- Summary: Resolving inner xsd with absolute path using includes Key: JBWS-4029 URL: https://issues.jboss.org/browse/JBWS-4029 Project: JBoss Web Services Issue Type: Bug Components: jbossws-cxf Reporter: Viral Gohel Attachments: xsd_catalog_resolving_with_catalog.zip CXF-6234 fixes the writing a new document and replaces public system id’s with class path id’s. However, before doing so, it checks whether the URL to rewrite is indeed in the set of resolved URL’s and schema’s. This set is not resolved correctly. It seems that the method WSDLGetUtils#getAndSaveRelativeSchemaLocationIfCatalogResolved is the culprit. It all depends on how the ‘doneSchemas’ hashmap is ordered. By some java source code investigation we found out how the hashing mechanism (and thus the sorting) in the ConcurrentHashMap works. This is how we devised the replicator. It uses such file names and URLs that the keys in the map are sorted in such a way that the problem occurs. Expected behavior when querying with the following URL: http://localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.o..., <schema elementFormDefault="qualified" targetNamespace="http://www.wsdlgetproblem.org/xsd/test/content" version="1.0.0"><include schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/xsd/..."/><include schemaLocation="http:// localhost:8080/jboss-helloworld-ws?xsd=http://www.wsdlgetproblem.org/xsd/..."/></schema> But.. I do get: <schema elementFormDefault="qualified" targetNamespace="http://www.wsdlgetproblem.org/xsd/test/content" version="1.0.0"><include schemaLocation="includedcontent_a.xsd"/><include schemaLocation="includedcontent_b.xsd"/></schema> * The trick in the reproducer is to find such filenames that they line up in a certain order in the ConcurrentHashMap. Most of the XSD/WSDL projects work, although there are far too many entries on the doneSchema's (as shown in the screenshot). To make the reproducer we tried to figure out which orders are correct and which not. Next we looked up the source of ConcurrentHashMap, checked its key hashing mechanism and constructed the path/file names of the XSD in such a way that they are sorted in the problematic order. It's not easy to trigger the right conditions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4028) Upgrade to Apache WSS4J 2.1.8

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-4028: ------------------------------------- Summary: Upgrade to Apache WSS4J 2.1.8 Key: JBWS-4028 URL: https://issues.jboss.org/browse/JBWS-4028 Project: JBoss Web Services Issue Type: Task Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.2.0.Final Upgrade to Apache WSS4J 2.1.8, in particular to pull fix for https://issues.apache.org/jira/browse/WSS-587 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4027) JDK 9 support

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4027?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-4027: --------------------------------------- WIP on branch https://github.com/jbossws/jbossws-cxf/tree/jdk9 > JDK 9 support > ------------- > > Key: JBWS-4027 > URL: https://issues.jboss.org/browse/JBWS-4027 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4027) JDK 9 support

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-4027: ------------------------------------- Summary: JDK 9 support Key: JBWS-4027 URL: https://issues.jboss.org/browse/JBWS-4027 Project: JBoss Web Services Issue Type: Feature Request Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.2.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4025) Content of modules-deploy.conf is outdated

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4025?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4025: ---------------------------------- Assignee: Alessio Soldano > Content of modules-deploy.conf is outdated > ------------------------------------------ > > Key: JBWS-4025 > URL: https://issues.jboss.org/browse/JBWS-4025 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-integration > Affects Versions: jbossws-cxf-5.1.5.Final > Reporter: Jan Blizňák > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.2.0.Final > > > If you try to install jbossws stack on WildFly, you will notice that not all JBWS related modules are removed before the new version is deployed which results in some files redundant after upgrade and in one case in file missing. > *The differences (ignoring version in filenames):* > upgrade deletes org/apache/httpcomponents module, bringing back only some files > -- org/apache/httpcomponents/main/httpmime-4.5.jar is missing in upgraded server > -- I suppose JBWS shouldn't remove the file just like that, especially when module is used by other module (missing dependency in jbossws?) > upgrade left org/apache/santuario/xmlsec/main/xmlsec-2.0.5.jar and org/apache/ws/xmlschema/main/xmlschema-core-2.2.1.jar files in place > -- modules-deploy.conf doesn't contain path for these modules to delete before upgrading > {color:grey}upgrade brings new jar org/apache/cxf/impl/main/cxf-rt-features-clustering.jar and new modules org/apache/cxf/services-sts, org/apache/cxf/ws-security, org/jboss/ws/cxf/sts > -- WF10 has 5.1.3.Final, files added in newer versions via JBWS-3984, JBWS-3981{color} > Files to delete listed from https://github.com/jbossws/jbossws-cxf/blob/master/modules/resources/src/... also contains masks that are not valid anymore for recent WildFly (tested WF 8.2+): > {noformat} > org/apache/ws/commons/xmlschema/**, > org/jboss/ws/jaxws-jboss-httpserver-httpspi/**, > org/springframework/spring/**, > {noformat} > Please revisit its content regarding above issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4025) Content of modules-deploy.conf is outdated

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4025?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-4025: ---------------------------------- Fix Version/s: jbossws-cxf-5.2.0.Final > Content of modules-deploy.conf is outdated > ------------------------------------------ > > Key: JBWS-4025 > URL: https://issues.jboss.org/browse/JBWS-4025 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-integration > Affects Versions: jbossws-cxf-5.1.5.Final > Reporter: Jan Blizňák > Fix For: jbossws-cxf-5.2.0.Final > > > If you try to install jbossws stack on WildFly, you will notice that not all JBWS related modules are removed before the new version is deployed which results in some files redundant after upgrade and in one case in file missing. > *The differences (ignoring version in filenames):* > upgrade deletes org/apache/httpcomponents module, bringing back only some files > -- org/apache/httpcomponents/main/httpmime-4.5.jar is missing in upgraded server > -- I suppose JBWS shouldn't remove the file just like that, especially when module is used by other module (missing dependency in jbossws?) > upgrade left org/apache/santuario/xmlsec/main/xmlsec-2.0.5.jar and org/apache/ws/xmlschema/main/xmlschema-core-2.2.1.jar files in place > -- modules-deploy.conf doesn't contain path for these modules to delete before upgrading > {color:grey}upgrade brings new jar org/apache/cxf/impl/main/cxf-rt-features-clustering.jar and new modules org/apache/cxf/services-sts, org/apache/cxf/ws-security, org/jboss/ws/cxf/sts > -- WF10 has 5.1.3.Final, files added in newer versions via JBWS-3984, JBWS-3981{color} > Files to delete listed from https://github.com/jbossws/jbossws-cxf/blob/master/modules/resources/src/... also contains masks that are not valid anymore for recent WildFly (tested WF 8.2+): > {noformat} > org/apache/ws/commons/xmlschema/**, > org/jboss/ws/jaxws-jboss-httpserver-httpspi/**, > org/springframework/spring/**, > {noformat} > Please revisit its content regarding above issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4003) [API] Add ClientConfigFeature(String configName) constructor

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-4003?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-4003: --------------------------------------- AFAIR, the reason why default configureProperties = false is that in the past not all implementations of ClientConfigurer supported properties setup. As for adding the additional constructor in ClientConfigFeature, I'd be fine with it but doing this(null, configName, false), that is with configureProperties = false, otherwise we'd have 2 different default behaviors (and at the same time I don't want to change the constructror with 2 parameters). A change in default behaviour would likely need a major API release, which is not really on the radar now... > [API] Add ClientConfigFeature(String configName) constructor > ------------------------------------------------------------ > > Key: JBWS-4003 > URL: https://issues.jboss.org/browse/JBWS-4003 > Project: JBoss Web Services > Issue Type: Feature Request > Reporter: Willem Salembier > > For predefined {{client-config}} settings in {{standalone.xml}}, it would be more elegant to add a new constructor in {{org.jboss.ws.api.configuration.ClientConfigFeature}} that only takes a configName and forces {{configureProperties=true}}. > {code} > public ClientConfigFeature(String configName) { > this(null, configName, true); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWS-4026) CDI injection does not work with SOAP over JMS endpoint

by Nikolay Boklaschuk (JIRA)

[ https://issues.jboss.org/browse/JBWS-4026?page=com.atlassian.jira.plugin.... ] Nikolay Boklaschuk commented on JBWS-4026: ------------------------------------------ I've explored sources of jbossws-cxf-server module and found that it support http endpoints only. Bootstrap of jbossws related stuff happens on servlet startup, but I don't know how should it be with jms transport, here we don't have servlet. May be someone could tell when @webservice annotation on endpoint implementor get processed, and where we can inject jboss related code to make additional processing on endpoints beans? > CDI injection does not work with SOAP over JMS endpoint > ------------------------------------------------------- > > Key: JBWS-4026 > URL: https://issues.jboss.org/browse/JBWS-4026 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Affects Versions: jbossws-cxf-5.1.5.Final > Reporter: Nikolay Boklaschuk > > Cannot inject via @Inject into endpoint implementation with soap over jms transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues September 2016