[jira] Created: (CXF-2486) Specify units for method arguments where relevant
Specify units for method arguments where relevant - Key: CXF-2486 URL: https://issues.apache.org/jira/browse/CXF-2486 Project: CXF Issue Type: Task Components: Documentation Reporter: Aleksander Adamowski There are places in javadoc, where there's no way to know what kinf of unit is accepted for a numeric argument. E.g.: timeout values in HTTPClientPolicy (http://cxf.apache.org/javadoc/latest/org/apache/cxf/transports/http/configuration/HTTPClientPolicy.html). After closer inspection of the code it seems that the values are in milliseconds. Adding this simple information in Javadoc would be of great help to many developers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2450) WSDL2java uses system encoding when generating java classes
[
https://issues.apache.org/jira/browse/CXF-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768235#action_12768235
]
nicolas de loof commented on CXF-2450:
--
This also affect CXF generated classes as they can derive method / parameter
names from the WSDL (operation and message), potentialy including some non
ASCII characters
The maven convention is to set encoding to ${project.build.sourceEncoding},
most plugins (including compiler) allready follow this best practice
> WSDL2java uses system encoding when generating java classes
> ---
>
> Key: CXF-2450
> URL: https://issues.apache.org/jira/browse/CXF-2450
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.1.3
>Reporter: Mads Jensen
>
> When using wsdl2java java classes are created in default encoding(for
> instance MacRoman). But when we afterwards try to compile these classes in
> UTF-8 special chars in java comments resolves in compliations error
> [INFO] Compilation failure
> /url/to/file/SomeFile.java:[31,18] unmappable character for encoding UTF-8
> We would like somehow to specify which encoding wsdl2java should use when
> generating java classes. We can't seem to find this property.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2486) Specify units for method arguments where relevant
[ https://issues.apache.org/jira/browse/CXF-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-2486: - CXF Fields: [Blocked on External] > Specify units for method arguments where relevant > - > > Key: CXF-2486 > URL: https://issues.apache.org/jira/browse/CXF-2486 > Project: CXF > Issue Type: Task > Components: Documentation >Reporter: Aleksander Adamowski > > There are places in javadoc, where there's no way to know what kinf of unit > is accepted for a numeric argument. E.g.: > timeout values in HTTPClientPolicy > (http://cxf.apache.org/javadoc/latest/org/apache/cxf/transports/http/configuration/HTTPClientPolicy.html). > After closer inspection of the code it seems that the values are in > milliseconds. Adding this simple information in Javadoc would be of great > help to many developers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2486) Specify units for method arguments where relevant
[ https://issues.apache.org/jira/browse/CXF-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768272#action_12768272 ] Daniel Kulp commented on CXF-2486: -- The class for this (and thus the javadoc) is generated via JAXB from the schema. The schema does have proper annotation/documentation things in it. See: http://cxf.apache.org/schemas/wsdl/http-conf.xsd This is really a JAXB bug: https://jaxb.dev.java.net/issues/show_bug.cgi?id=172 Feel free to vote on it there, but with 72 votes already, it's obviously not something they care too much about. :-( I was going to comment on their issue pointing back to here, but they seem to have taken away my ability to comment there. dev.java.net has had a BUNCH of issues lately so something might be amiss there. > Specify units for method arguments where relevant > - > > Key: CXF-2486 > URL: https://issues.apache.org/jira/browse/CXF-2486 > Project: CXF > Issue Type: Task > Components: Documentation >Reporter: Aleksander Adamowski > > There are places in javadoc, where there's no way to know what kinf of unit > is accepted for a numeric argument. E.g.: > timeout values in HTTPClientPolicy > (http://cxf.apache.org/javadoc/latest/org/apache/cxf/transports/http/configuration/HTTPClientPolicy.html). > After closer inspection of the code it seems that the values are in > milliseconds. Adding this simple information in Javadoc would be of great > help to many developers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2487) SecureConversationTokenFinderInterceptor stores the wrong token identifier
[ https://issues.apache.org/jira/browse/CXF-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-2487: - Attachment: cxf-2487.patch A patch for this issue. Colm. > SecureConversationTokenFinderInterceptor stores the wrong token identifier > -- > > Key: CXF-2487 > URL: https://issues.apache.org/jira/browse/CXF-2487 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.2.4 >Reporter: Colm O hEigeartaigh > Fix For: 2.2.5, 2.3 > > Attachments: cxf-2487.patch > > > The SecureConversationTokenFinderInterceptor in CXF has this line: > message.getExchange().put(SecurityConstants.TOKEN_ID, tok.getID()); > but it also stores the token like so: > SecurityToken token = new SecurityToken(sct.getIdentifier(), created, > expires); > Then in AbstractBindingBuilder.getSecurityToken() it tries to find the token > in the token store using SecurityConstants.TOKEN_ID, and an error of "No > signature token id" is thrown. The SecureConversationTokenFinderInterceptor > should store the Identifier of the SCT instead (getIdentifier, not getIDI()). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2487) SecureConversationTokenFinderInterceptor stores the wrong token identifier
SecureConversationTokenFinderInterceptor stores the wrong token identifier -- Key: CXF-2487 URL: https://issues.apache.org/jira/browse/CXF-2487 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.2.4 Reporter: Colm O hEigeartaigh Fix For: 2.2.5, 2.3 Attachments: cxf-2487.patch The SecureConversationTokenFinderInterceptor in CXF has this line: message.getExchange().put(SecurityConstants.TOKEN_ID, tok.getID()); but it also stores the token like so: SecurityToken token = new SecurityToken(sct.getIdentifier(), created, expires); Then in AbstractBindingBuilder.getSecurityToken() it tries to find the token in the token store using SecurityConstants.TOKEN_ID, and an error of "No signature token id" is thrown. The SecureConversationTokenFinderInterceptor should store the Identifier of the SCT instead (getIdentifier, not getIDI()). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2487) SecureConversationTokenFinderInterceptor stores the wrong token identifier
[ https://issues.apache.org/jira/browse/CXF-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-2487. -- Resolution: Fixed Assignee: Daniel Kulp Patch applied. > SecureConversationTokenFinderInterceptor stores the wrong token identifier > -- > > Key: CXF-2487 > URL: https://issues.apache.org/jira/browse/CXF-2487 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.2.4 >Reporter: Colm O hEigeartaigh >Assignee: Daniel Kulp > Fix For: 2.2.5, 2.3 > > Attachments: cxf-2487.patch > > > The SecureConversationTokenFinderInterceptor in CXF has this line: > message.getExchange().put(SecurityConstants.TOKEN_ID, tok.getID()); > but it also stores the token like so: > SecurityToken token = new SecurityToken(sct.getIdentifier(), created, > expires); > Then in AbstractBindingBuilder.getSecurityToken() it tries to find the token > in the token store using SecurityConstants.TOKEN_ID, and an error of "No > signature token id" is thrown. The SecureConversationTokenFinderInterceptor > should store the Identifier of the SCT instead (getIdentifier, not getIDI()). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2488) Mangled error message for JAX-RS missing writer
Mangled error message for JAX-RS missing writer --- Key: CXF-2488 URL: https://issues.apache.org/jira/browse/CXF-2488 Project: CXF Issue Type: Bug Components: REST Affects Versions: 2.3 Reporter: Benson Margulies Priority: Minor 109452 [http-8080-1] WARN org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body writer found for response class : ArrayList. 109534 [http-8080-1] WARN org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body writer found for response class : ArrayList. 186175 [http-8080-1] WARN org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body writer found for response class : ArrayList. 186213 [http-8080-1] WARN org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body writer found for response class : ArrayList. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2489) Exceptions are not properly handled by Performance.Counter MBean
Exceptions are not properly handled by Performance.Counter MBean
Key: CXF-2489
URL: https://issues.apache.org/jira/browse/CXF-2489
Project: CXF
Issue Type: Bug
Affects Versions: 2.2.4
Reporter: Oliver Wulff
I've updated the ws-security\ut sample and added the management dependency in
the pom and updated the wssec.xml for the server:
Run the server with: mvn -Pserver
Run the client with: mvn -Pclient
8 invocations will occur.
Now, change the UTPasswordCallback.java of the client (done already in
attachment)
public UTPasswordCallback() {
passwords.put("Alice", "ecilACHANGED");
passwords.put("abcd", "dcbaCHANGED");
}
and run the client again. There is no update in the Performance.Counter MBean.
I also noticed that the Performance.Counter MBean is not visible in the
JConsole till the first request is processed.
When my first run is with invalid passwords, the Performance.Counter MBean is
not added in the JConsole.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2489) Exceptions are not properly handled by Performance.Counter MBean
[
https://issues.apache.org/jira/browse/CXF-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Wulff updated CXF-2489:
--
Attachment: ut.zip
> Exceptions are not properly handled by Performance.Counter MBean
>
>
> Key: CXF-2489
> URL: https://issues.apache.org/jira/browse/CXF-2489
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Oliver Wulff
> Attachments: ut.zip
>
>
> I've updated the ws-security\ut sample and added the management dependency in
> the pom and updated the wssec.xml for the server:
> class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>
>
>
>
> value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>
>
> class="org.apache.cxf.management.counters.CounterRepository">
>
>
> Run the server with: mvn -Pserver
> Run the client with: mvn -Pclient
> 8 invocations will occur.
> Now, change the UTPasswordCallback.java of the client (done already in
> attachment)
> public UTPasswordCallback() {
> passwords.put("Alice", "ecilACHANGED");
> passwords.put("abcd", "dcbaCHANGED");
> }
> and run the client again. There is no update in the Performance.Counter MBean.
> I also noticed that the Performance.Counter MBean is not visible in the
> JConsole till the first request is processed.
> When my first run is with invalid passwords, the Performance.Counter MBean is
> not added in the JConsole.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2490) Wrong content type for JAX-RS errors
Wrong content type for JAX-RS errors Key: CXF-2490 URL: https://issues.apache.org/jira/browse/CXF-2490 Project: CXF Issue Type: Bug Components: REST Affects Versions: 2.3 Reporter: Benson Margulies When my JAX-RS service suffers from: ".No message body writer found for response class : ArrayList" The content type of the error message is text/xml, and should be text/plain. Server: Apache-Coyote/1.1 Date: Wed, 21 Oct 2009 19:42:33 GMT Content-Type: text/xml Content-Length: 61 Connection: close 500 Internal Server Error -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2352) dOSGi creates new databinding instance instead of using a spring-loaded databinding if available
[ https://issues.apache.org/jira/browse/CXF-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated CXF-2352: -- Component/s: (was: Aegis Databinding) Distributed-OSGi > dOSGi creates new databinding instance instead of using a spring-loaded > databinding if available > > > Key: CXF-2352 > URL: https://issues.apache.org/jira/browse/CXF-2352 > Project: CXF > Issue Type: Bug > Components: Distributed-OSGi >Affects Versions: dOSGi-1.1 >Reporter: Ahmed Aadel > Fix For: dOSGi-1.1 > > > It seems dOSGI doesn't look for the user spring-configured data binding > instance but instead creates and uses a new one, leading to a faulty context > with default properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1459) ClassCastException occurs on HTTPS web service call made by app deployed to BEA WebLogic 9.2
[ https://issues.apache.org/jira/browse/CXF-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768505#action_12768505 ] Vamsee Koneru commented on CXF-1459: I'm working on a project that uses CXF 2.2.2 and am seeing this same problem. Not sure if this is the right place to ask, but I'm waiting on this fix to do a release of this project. Is there an estimated release date for CXF 2.2.5, or plans to roll this fix into 2.2.4 or older versions soon? Modifying the WL startup script is a non-option because of other applications running in the same environment. Thanks. > ClassCastException occurs on HTTPS web service call made by app deployed to > BEA WebLogic 9.2 > > > Key: CXF-1459 > URL: https://issues.apache.org/jira/browse/CXF-1459 > Project: CXF > Issue Type: Improvement > Components: Integration >Affects Versions: 2.0.4 >Reporter: Tom Schroedl >Assignee: Daniel Kulp > Fix For: 2.2.5 > > Attachments: HttpsURLConnectionFactory.patch > > > HTTPS web service call fails from webapp deployed in ear file to BEA 9.2 with > following error: > java.lang.ClassCastException: weblogic.net.http.SOAPHttpsURLConnection >at > org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:120) > My weblogic-application.xml contains: > >javax.jws.* > > The secure web service call works in Tomcat 5.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
