[jira] Updated: (CXF-3142) BusFactory holds static reference to defaultBus
[ https://issues.apache.org/jira/browse/CXF-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated CXF-3142: - Fix Version/s: 2.3.1 2.2.12 This seems to have been ported to 2.2.x and 2.3.x branches too, so updating the fix version accordingly. > BusFactory holds static reference to defaultBus > --- > > Key: CXF-3142 > URL: https://issues.apache.org/jira/browse/CXF-3142 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 2.3.0, 2.2.11 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.2.12, 2.3.1, 2.4 > > > BusFactory.defaultBus is a static strong reference. I think I've proved that > this is why CXF builds like to run out of memory. > I have a fix, I think, but I thought that this was a change that deserved > tracking in JIRA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3149) WebClient getCollection() doesn't work with Jackson's JSON Provider because it passes the wrong types to readFrom()
[
https://issues.apache.org/jira/browse/CXF-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-3149.
---
Resolution: Fixed
Fix Version/s: 2.4
2.3.1
Assignee: Sergey Beryozkin
Brilliant, patch has been applied, thanks.
Personally I'd expect 3rd party providers be more 'tolerant' (ex, CXF
JAXBProvider works either way) but agree this fix is a useful one.
> WebClient getCollection() doesn't work with Jackson's JSON Provider because
> it passes the wrong types to readFrom()
> ---
>
> Key: CXF-3149
> URL: https://issues.apache.org/jira/browse/CXF-3149
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.3.0
>Reporter: Dobes Vandermeer
>Assignee: Sergey Beryozkin
> Fix For: 2.3.1, 2.4
>
>
> When you request a collection from the WebClient it calls readFrom() using
> the type == Collection.class and the genericType == the member type of the
> class.
> Unfortunately, this isn't what is normally passed as the genericType when
> reflection or a GenericEntity was used to write out an object. Normally, the
> genericType == Collection. In order to be more compatible with
> third-party providers, it would be best if the generic type was set
> consistently in each case, rather than having a special case for the
> collections.
> To support this, the genericType should be set to a subclass of
> ParameterizedType, for example an instance of this class:
> {code}
> import java.lang.reflect.ParameterizedType;
> import java.lang.reflect.Type;
> import java.util.Collection;
> public final class ParameterizedCollectionType implements
> ParameterizedType {
> private final Class collectionMemberClass;
> private final Type[] typeArgs;
> public ParameterizedCollectionType(Class collectionMemberClass) {
> this.collectionMemberClass=collectionMemberClass;
> this.typeArgs=new Type[] { collectionMemberClass };
> }
>
> public Type[] getActualTypeArguments() {
> return typeArgs;
> }
> public Type getOwnerType() {
> return null;
> }
> public Type getRawType() {
> return Collection.class;
> }
> public String toString() {
> return
> "java.util.Collection<"+collectionMemberClass.getName()+">";
> }
> }
> {code}
> If this class was used in
> org.apache.cxf.jaxrs.client.WebClient.invokeAndGetCollection(String, Object,
> Class) then the client would be able to read a JSON collection response
> using the JacksonJsonProvider.
> As a workaround I have created a subclass of JacksonJsonProvider that "fixes"
> this issue by overriding readFrom():
> {code}
> /**
>* For collections, CXF passes type == Collection.class and genericType
> == the member class type.
>*
>* But actually, it should pass genericType = Collection as the
> generic type in order for Jackson
>* to understand it.
>*/
> @SuppressWarnings("unchecked")
> @Override
> public Object readFrom(Class type, Type genericType,
> Annotation[] annotations, MediaType mediaType,
> MultivaluedMap httpHeaders, InputStream
> entityStream) throws IOException {
> if(type.equals(Collection.class) && !(genericType instanceof
> ParameterizedType)) {
> genericType = new
> ParameterizedCollectionType((Class)genericType);
> }
> return super.readFrom(type, genericType, annotations,
> mediaType, httpHeaders, entityStream);
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3126) CXF example mvn -Pserver complain about the can't find right version of exec-maven-plugin
[
https://issues.apache.org/jira/browse/CXF-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CXF-3126.
---
Resolution: Fixed
> CXF example mvn -Pserver complain about the can't find right version of
> exec-maven-plugin
> -
>
> Key: CXF-3126
> URL: https://issues.apache.org/jira/browse/CXF-3126
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Willem Jiang
>Assignee: Willem Jiang
> Fix For: 2.3.1
>
>
> {code}
> Project ID: org.codehaus.mojo:exec-maven-plugin
> Reason: Error getting POM for 'org.codehaus.mojo:exec-maven-plugin' from the
> repository: Failed to resolve artifact, possibly due to a repository list
> that is not appropriately equipped for this artifact's metadata.
> org.codehaus.mojo:exec-maven-plugin:pom:1.1.2-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> for project org.codehaus.mojo:exec-maven-plugin
> {code}
> We just need update the dependency version in the example pom.xml.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3126) CXF example mvn -Pserver complain about the can't find right version of exec-maven-plugin
[
https://issues.apache.org/jira/browse/CXF-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CXF-3126:
--
Fix Version/s: 2.4
2.2.12
> CXF example mvn -Pserver complain about the can't find right version of
> exec-maven-plugin
> -
>
> Key: CXF-3126
> URL: https://issues.apache.org/jira/browse/CXF-3126
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Willem Jiang
>Assignee: Willem Jiang
> Fix For: 2.2.12, 2.3.1, 2.4
>
>
> {code}
> Project ID: org.codehaus.mojo:exec-maven-plugin
> Reason: Error getting POM for 'org.codehaus.mojo:exec-maven-plugin' from the
> repository: Failed to resolve artifact, possibly due to a repository list
> that is not appropriately equipped for this artifact's metadata.
> org.codehaus.mojo:exec-maven-plugin:pom:1.1.2-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> for project org.codehaus.mojo:exec-maven-plugin
> {code}
> We just need update the dependency version in the example pom.xml.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3142) BusFactory holds static reference to defaultBus
[ https://issues.apache.org/jira/browse/CXF-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-3142: - Fix Version/s: (was: 2.3.1) (was: 2.2.12) Only the javadoc additions were ported back since that was useful, not the weak reference things. > BusFactory holds static reference to defaultBus > --- > > Key: CXF-3142 > URL: https://issues.apache.org/jira/browse/CXF-3142 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 2.3.0, 2.2.11 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.4 > > > BusFactory.defaultBus is a static strong reference. I think I've proved that > this is why CXF builds like to run out of memory. > I have a fix, I think, but I thought that this was a change that deserved > tracking in JIRA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3153) doesn't work when the wsdlLocation is provided
doesn't work when the wsdlLocation is provided -- Key: CXF-3153 URL: https://issues.apache.org/jira/browse/CXF-3153 Project: CXF Issue Type: Bug Reporter: jimma If the MTOM is not enabled in the wsdl , the mtom can not be activated through spring configuration xml : http://localhost:9090/mtomTest";> We probably can provide another mtom element parser like wsa parser to add it to the feature list and activate the Mtom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3153) doesn't work when the wsdlLocation is provided
[ https://issues.apache.org/jira/browse/CXF-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jimma updated CXF-3153: --- Component/s: JAX-WS Runtime Affects Version/s: 2.3.0 Fix Version/s: 2.4 Assignee: jimma > doesn't work when the wsdlLocation is > provided > -- > > Key: CXF-3153 > URL: https://issues.apache.org/jira/browse/CXF-3153 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 2.3.0 >Reporter: jimma >Assignee: jimma > Fix For: 2.4 > > > If the MTOM is not enabled in the wsdl , the mtom can not be activated > through spring configuration xml : > address="http://localhost:9090/mtomTest";> > > > We probably can provide another mtom element parser like wsa parser to add it > to the feature list and activate the Mtom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3151) Invalid WS-A ReplyTo constant value used by WS-RM
[ https://issues.apache.org/jira/browse/CXF-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-3151. --- Resolution: Fixed Fix Version/s: 2.4 2.3.1 apply patch on behalf of Aki Yoshida with thanks http://svn.apache.org/viewvc?rev=1039249&view=rev for trunk http://svn.apache.org/viewvc?rev=1039250&view=rev for 2.3 branch http://svn.apache.org/viewvc?rev=1039254&view=rev for 2.2 branch > Invalid WS-A ReplyTo constant value used by WS-RM > - > > Key: CXF-3151 > URL: https://issues.apache.org/jira/browse/CXF-3151 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.2.11 >Reporter: Aki Yoshida >Assignee: Freeman Fang > Fix For: 2.2.12, 2.3.1, 2.4 > > Attachments: svndiff.zip > > > There is an issue in the way how the current WS-RM implementation > downgrades the WS-A namespace/constants to the 2004/08 version. I > would like to first explain the problem and ask you which solution is > preferred. > CXF uses WS-A 2005/08 internally but for WS-RM, it uses the 2004/08 > version because the older WS-RM (1.0) > requires the use of the 2004/08 version. So, it is correct to convert > the internally used 2005/08 namespace/constants to their 2004/08 > counterparts. > However, one problem is that the 2005/08 WS-A spec defined two constants > http://www.w3.org/2005/08/addressing/anonymous > http://www.w3.org/2005/08/addressing/none > While the 2004/08 WS-A version seems to have only defined > http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous > and not > http://schemas.xmlsoap.org/ws/2004/08/addressing/role/none > The current conversion used in CXF creates this undefined value and > this is causing some interoperability issues. > More concretely, when the WS-A ReplyTo element is set to the none > value and this is serialized into the above undefined 2004/08 none > constant, it is not recognized by some systems. According to the WS-RM > 1.0, in such a case, the ReplyTo element should be omitted to convey > this "none" value (as there is no "none" constant). > Initially, I thought we should fix this issue by introducing a configurable > property "usingNoneAddress" for the addressing configuration bean to turn on > or off the serialization of the none address. However, this approach had a > drawback on requiring a different default value interpretation based on the > used namespace versions (i.e., false for 2004/08 and true for 2005/08) to > make the test cases all work. > Therefore, I am proposing the following approach to solve this issue. > There is no configuration property. The serialization is determined by the > addressing namespace. Under 2004/08, the none value is omitted from > serialization, while under 2005/08, the none value is serialized. > This will work for all the current tests except for the testVersioning test > of MAPTest. This particular test uses the 2004/08 namespace and checks the > presence of the ReplyTo header in the SOAP header, even though the header is > associated with the none value and therefore it must not be present. In order > to fix this test, I needed to modify the corresponding verification classes > so that the presence of the ReplyTo header is not verified when the 2004/08 > namespace is used. > In summary, the changes that I suggest are as follows: > For the runtime ws.addressing: > org.apache.cxf.ws.addressing.soap.MAPCodec > The ReplyTo header will not be serialized with the invalid none value. In > other words, if the value is set to the none value while using the 2004/08 > namespace. > org.apache.cxf.ws.addressing.ContextUtils > The back channel will be found even when the ReplyTo header is missing. > For the systests ws.addressing > org.apache.cxf.systest.ws.addressing MAPTestBase > Its verifyHeaders method takes additionally a Boolean parameter > replyToRequired to indicate whether the presence of the ReplyTo header must > be verified. > org.apache.cxf.systest.ws.addressing HeaderVerifier > Its verify method call the above verityHeaders method with the > replyToRequired parameter set based on the namespace version. > The svn diff files of the above changes are attached. > Regards, Aki -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
