[jira] [Resolved] (CXF-4176) preserve namespace prefixes in Transform Feature to support QName resolution for content
[
https://issues.apache.org/jira/browse/CXF-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida resolved CXF-4176.
--
Resolution: Fixed
Fix Version/s: 2.6
2.5.3
This patch preserves the namespace prefixes. More specifically, all non empty
prefixes are preserved. Empty prefixes are preserved except when the outbound
transformer explicitly configures the default namespace to be changed (In this
case, the existing default namespace is assigned a new generated prefix).
In addition, another situation where a new prefix is generated is when an
unqualified element is promoted to be an qualified element (i.e., mapped to a
qualified element).
> preserve namespace prefixes in Transform Feature to support QName resolution
> for content
>
>
> Key: CXF-4176
> URL: https://issues.apache.org/jira/browse/CXF-4176
> Project: CXF
> Issue Type: Improvement
>Reporter: Aki Yoshida
>Assignee: Aki Yoshida
> Fix For: 2.5.3, 2.6
>
>
> Unless configured specifically otherwise (i.e., using the default namespace
> option to switch the default namespace), the original namespace prefixes
> should be preserved in the resulting XML document so that an element content
> typed as QName can be resolved against the namespace context.
> For example, if you have an input XML:
>
> a2:text
>
> and suppose the content of element bar is of type QName.
> If we are transforming from {urn:abc}* to {urn:a}*, we should not
> simply generate:
>
> a2:text
>
> Instead, we should generate:
>
> a2:text
>
> so that the QName a2:text can be correctly interpreted.
> http://cxf.547215.n5.nabble.com/Transform-feature-to-preserve-prefix-values-Re-svn-commit-r1295714-tt5538162.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4084) Blueprint http
[ https://issues.apache.org/jira/browse/CXF-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-4084. -- Resolution: Fixed Assignee: Aki Yoshida > Blueprint http > -- > > Key: CXF-4084 > URL: https://issues.apache.org/jira/browse/CXF-4084 > Project: CXF > Issue Type: New Feature > Components: Transports >Affects Versions: 2.5 >Reporter: Tony Su >Assignee: Aki Yoshida >Priority: Minor > Fix For: 2.5.3, 2.6 > > > Some initial support for blueprint was provided in 2.4, but there are still > additional schemas that need porting. > Add support for http transport blueprint namespace handlers, parser and > typeconverters -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4229) Make upgrading the WS-RM's RMTxStore's tables definitions easier
[ https://issues.apache.org/jira/browse/CXF-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-4229. -- Resolution: Fixed For now, we keep this only in 2.6.0. This patch is needed for those who have the older 2.5.x RMStore tables and are upgrading to 2.6.x which has a new column added in the RM sequence tables by CXF-4218. If we integrate CXF-4118 to 2.5.x, we will also need to integrate this patch to 2.5.x. > Make upgrading the WS-RM's RMTxStore's tables definitions easier > > > Key: CXF-4229 > URL: https://issues.apache.org/jira/browse/CXF-4229 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.5.2 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6 > > > When a new column is added to one of the RMTxStore's tables in a newer > release, the table created earlier must be upgraded to include this new > column with its default value. > Previously, the old tables must be dropped and the tables must be newly > created. > This patch includes the automatic upgrading code that automatically adds the > new columns to the old tables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DOSGI-117) Stopping single bundle distribution hits NPE at org.apache.felix.cm.impl.ConfigurationManager.stop line: 267
Stopping single bundle distribution hits NPE at org.apache.felix.cm.impl.ConfigurationManager.stop line: 267 Key: DOSGI-117 URL: https://issues.apache.org/jira/browse/DOSGI-117 Project: CXF Distributed OSGi Issue Type: Bug Affects Versions: 1.3 Environment: CXF single bundle distribution 1.3.0 ZooKeeper 3.4.3 java version "1.6.0_29" Mac OS X 10.7.3 Reporter: Glyn Normington The following NPE occurs in Felix Config Admin when stopping the single bundle distribution of CXF dosgi. It seems likely that the NPE will be fixed by FELIX-2813 which was implemented in Felix Config Admin 1.4.0, so the fix to this bug is to upgrade Felix Config Admin to 1.4.0. Daemon Thread [Thread-34] (Suspended (exception java.lang.NullPointerException)) org.apache.felix.cm.impl.ConfigurationManager.stop(org.osgi.framework.BundleContext) line: 267 org.apache.cxf.dosgi.singlebundle.AggregatedActivator.stopEmbeddedActivators(org.osgi.framework.BundleContext) line: 137 org.apache.cxf.dosgi.singlebundle.AggregatedActivator.stop(org.osgi.framework.BundleContext) line: 51 org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run() line: 771 java.security.AccessController.doPrivileged(java.security.PrivilegedExceptionAction) line: not available [native method] org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop() line: 764 org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(int) line: 510 org.eclipse.osgi.framework.internal.core.BundleHost(org.eclipse.osgi.framework.internal.core.AbstractBundle).stop(int) line: 464 org.apache.felix.gogo.command.Basic.stop(boolean, org.osgi.framework.Bundle[]) line: 817 sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) line: not available [native method] sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 39 sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 25 java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) line: 597 org.apache.felix.gogo.runtime.Reflective.method(org.apache.felix.service.command.CommandSession, java.lang.Object, java.lang.String, java.util.List) line: 136 org.apache.felix.gogo.runtime.CommandProxy.execute(org.apache.felix.service.command.CommandSession, java.util.List) line: 82 org.apache.felix.gogo.runtime.Closure.executeCmd(java.lang.String, java.util.List) line: 469 org.apache.felix.gogo.runtime.Closure.executeStatement(java.util.List) line: 395 org.apache.felix.gogo.runtime.Pipe.run() line: 108 org.apache.felix.gogo.runtime.Closure.execute(java.util.List) line: 183 org.apache.felix.gogo.runtime.Closure.execute(org.apache.felix.service.command.CommandSession, java.util.List) line: 120 org.apache.felix.gogo.runtime.CommandSessionImpl.execute(java.lang.CharSequence) line: 89 org.apache.felix.gogo.shell.Console.run() line: 62 org.apache.felix.gogo.shell.Shell.console(org.apache.felix.service.command.CommandSession) line: 203 org.apache.felix.gogo.shell.Shell.gosh(org.apache.felix.service.command.CommandSession, java.lang.String[]) line: 128 sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) line: not available [native method] sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 39 sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 25 java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) line: 597 org.apache.felix.gogo.runtime.Reflective.method(org.apache.felix.service.command.CommandSession, java.lang.Object, java.lang.String, java.util.List) line: 136 org.apache.felix.gogo.runtime.CommandProxy.execute(org.apache.felix.service.command.CommandSession, java.util.List) line: 82 org.apache.felix.gogo.runtime.Closure.executeCmd(java.lang.String, java.util.List) line: 469 org.apache.felix.gogo.runtime.Closure.executeStatement(java.util.List) line: 395 org.apache.felix.gogo.runtime.Pipe.run() line: 108 org.apache.felix.gogo.runtime.Closure.execute(java.util.List) line: 183 org.apache.felix.gogo.runtime.Closure.execute(org.apache.felix.service.command.CommandSession, java.util.List) line: 120 org.apache.felix.gogo.runtime.CommandSessionImpl.exe
COnsuming WCF web service using CXF WSS4J
I wrote a CXF client for WCF web service and got the "Signing without primary signature requires timestamp" error from the WCF server even the timestamp is sent. This is because of the ordering of the timestamp tag in the SOAP Security header. I want to write a CXF Interceptor which can reorder the headers in SOAP header as I want. Can someone help? -- View this message in context: http://cxf.547215.n5.nabble.com/COnsuming-WCF-web-service-using-CXF-WSS4J-tp5629381p5629381.html Sent from the cxf-issues mailing list archive at Nabble.com.
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic instead of String
[
https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250582#comment-13250582
]
Sergey Beryozkin commented on CXF-4221:
---
Hi, thanks for this effort, here are some comments.
In the code example, SearchContext is completely bypassed,
searchContext.getSearchExpression() is a utility method which is indeed can be
handy but it's effectively the same as providing a JAX-RS QueryParam("_s"). The
idea behind SearchContext (and SearchCondition + SearchConditionVisitor) is to
completely hide the fact it is a FiqlParser that is being used to parse a given
search expression, this way it is possible to transparently manage different
search languages, something different to FIQL for example.
To be honest, I do not see why FiqlParser should depend on
"javax.persistence.criteria CriteriaBuilder,
Predicate, Root".
I'm interested in exploring the new options for making the Search extension be
more useful, but I'd like us to think of different options.
First let me suggest that we do not deal with the nested properties, which
require the use of beanutils, it is a different issue altogether, so we can
return to it later on.
The issue at hand is how to make it easier to adapt the search expressions to
JPA handlers (CriteriaBuilder, Predicate, Root, etc) but *without* having to
introduce the javax persistence dependencies directly into the FIQL parser,
rather I'd prefer to introduce something like JPACriteriaVisitor or something
like that.
SearchConditionVisitor has a 'getResult()' method returning String.
JPACriteriaVisitor may have this method unimplemented but offer it's own
getPredicate() method and be initialized with CriteriaQuery & Root,
etc.
Can you consider prototyping such a visitor ? After that it will be easier for
me to see what can be pushed to the core Search code to simplify the code for
the JPA visitor
> FIQL visitor to return a generic instead of String
> --
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Szu-Yu Wang
> Attachments: FiqlParser.java
>
>
> It would be great if SearchConditionVisitor where K was the return type
> of the getResult() call. This way, I can CriteriaQuery instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like
> "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4226) @Description on class level not "inherited"
[
https://issues.apache.org/jira/browse/CXF-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250590#comment-13250590
]
Jakub Bocheński commented on CXF-4226:
--
Hi, I tried 20120403.080549 snapshot of 2.5.3 and this still happens (when I
move annotation from implementation to interface it's not included in the
generated WADL)
> @Description on class level not "inherited"
> ---
>
> Key: CXF-4226
> URL: https://issues.apache.org/jira/browse/CXF-4226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Priority: Minor
>
> This is really a minor one: if you define a resource via interface
> {code}@Description(title = "My resource")
> interface AResource {
> @GET
> @Description(title = "bar")
> Response foo();
> }{code}
> and then implement it:
> {code}class ResourceImpl {
> Response foo(){
> return Response.ok().build();
> }
> }{code}
> Then the generated WADL document will contain the method description ("bar")
> but not the resource level description ("My resource").
> Workaround: annotate concrete implementation classes - this is of course
> rather tedious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4226) @Description on class level not "inherited"
[
https://issues.apache.org/jira/browse/CXF-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Bocheński updated CXF-4226:
-
Description:
This is really a minor one: if you define a resource via interface
{code}@Description(title = "My resource")
interface AResource {
@GET
@Description(title = "bar")
Response foo();
}{code}
and then implement it:
{code}class ResourceImpl implements AResource{
Response foo(){
return Response.ok().build();
}
}{code}
Then the generated WADL document will contain the method description ("bar")
but not the resource level description ("My resource").
Workaround: annotate concrete implementation classes - this is of course rather
tedious.
was:
This is really a minor one: if you define a resource via interface
{code}@Description(title = "My resource")
interface AResource {
@GET
@Description(title = "bar")
Response foo();
}{code}
and then implement it:
{code}class ResourceImpl {
Response foo(){
return Response.ok().build();
}
}{code}
Then the generated WADL document will contain the method description ("bar")
but not the resource level description ("My resource").
Workaround: annotate concrete implementation classes - this is of course rather
tedious.
I fixed an error in example (the resource class implements the interface obv.)
> @Description on class level not "inherited"
> ---
>
> Key: CXF-4226
> URL: https://issues.apache.org/jira/browse/CXF-4226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Priority: Minor
>
> This is really a minor one: if you define a resource via interface
> {code}@Description(title = "My resource")
> interface AResource {
> @GET
> @Description(title = "bar")
> Response foo();
> }{code}
> and then implement it:
> {code}class ResourceImpl implements AResource{
> Response foo(){
> return Response.ok().build();
> }
> }{code}
> Then the generated WADL document will contain the method description ("bar")
> but not the resource level description ("My resource").
> Workaround: annotate concrete implementation classes - this is of course
> rather tedious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4224) Custom HTTP methods (HttpMethod annot) not supported?
[
https://issues.apache.org/jira/browse/CXF-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250596#comment-13250596
]
Jakub Bocheński commented on CXF-4224:
--
Thanks, I tried this again and must say that it is working now - at least with
2.5.3-20120403.080549-37.
Sorry for the hassle - most likely there was something wrong with auto
publishig to my dev Tomcat.
> Custom HTTP methods (HttpMethod annot) not supported?
> -
>
> Key: CXF-4224
> URL: https://issues.apache.org/jira/browse/CXF-4224
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Assignee: Sergey Beryozkin
>
> I wanted to save myself some typing and introduce a custom method annotation
> for use with a response handler:
> @Target(value = METHOD)
> @Retention(value = RUNTIME)
> @HttpMethod(value = POST)
> public @interface POST_create {
> }
> since HATEOS resource creation is done with POST.
> However a method:
> @POST_create
> @Consumes(CONTENT_FORM_URLENCODED)
> @Description(title = "Factory method")
> Dto createSomething( ... );
> is not found as valid resource method.
> When I annotate it with regular POST annot. it works:
> @POST
> @POST_create
> @Consumes(CONTENT_FORM_URLENCODED)
> @Description(title = "Factory method")
> Dto createSomething( ... );
> BTW. While trying to debug this I noticed that the HttpMethod annotation is
> still recognized as a valid resource method annotation ( c.f. CXF-1007 ) in
> org.apache.cxf.jaxrs.utils.AnnotationUtils.initMethodAnnotationClasses() line
> 114
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4224) Custom HTTP methods (HttpMethod annot) not supported?
[
https://issues.apache.org/jira/browse/CXF-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250598#comment-13250598
]
Sergey Beryozkin commented on CXF-4224:
---
np, thanks for confirming it, and having a new test added did not 'harm' the
CXF too :-)
> Custom HTTP methods (HttpMethod annot) not supported?
> -
>
> Key: CXF-4224
> URL: https://issues.apache.org/jira/browse/CXF-4224
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Assignee: Sergey Beryozkin
>
> I wanted to save myself some typing and introduce a custom method annotation
> for use with a response handler:
> @Target(value = METHOD)
> @Retention(value = RUNTIME)
> @HttpMethod(value = POST)
> public @interface POST_create {
> }
> since HATEOS resource creation is done with POST.
> However a method:
> @POST_create
> @Consumes(CONTENT_FORM_URLENCODED)
> @Description(title = "Factory method")
> Dto createSomething( ... );
> is not found as valid resource method.
> When I annotate it with regular POST annot. it works:
> @POST
> @POST_create
> @Consumes(CONTENT_FORM_URLENCODED)
> @Description(title = "Factory method")
> Dto createSomething( ... );
> BTW. While trying to debug this I noticed that the HttpMethod annotation is
> still recognized as a valid resource method annotation ( c.f. CXF-1007 ) in
> org.apache.cxf.jaxrs.utils.AnnotationUtils.initMethodAnnotationClasses() line
> 114
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4226) @Description on class level not "inherited"
[
https://issues.apache.org/jira/browse/CXF-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250603#comment-13250603
]
Jakub Bocheński commented on CXF-4226:
--
For the record, I also tried specifying the target explicitly, e.g.
{code}@Description(title = "My resource", target = DocTarget.RESOURCE)
interface AResource {{code}
> @Description on class level not "inherited"
> ---
>
> Key: CXF-4226
> URL: https://issues.apache.org/jira/browse/CXF-4226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Priority: Minor
>
> This is really a minor one: if you define a resource via interface
> {code}@Description(title = "My resource")
> interface AResource {
> @GET
> @Description(title = "bar")
> Response foo();
> }{code}
> and then implement it:
> {code}class ResourceImpl implements AResource{
> Response foo(){
> return Response.ok().build();
> }
> }{code}
> Then the generated WADL document will contain the method description ("bar")
> but not the resource level description ("My resource").
> Workaround: annotate concrete implementation classes - this is of course
> rather tedious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4234) JAX-RS JAASAuthenticatingFilter leaks SecurityException
JAX-RS JAASAuthenticatingFilter leaks SecurityException --- Key: CXF-4234 URL: https://issues.apache.org/jira/browse/CXF-4234 Project: CXF Issue Type: Bug Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.5.3, 2.6 JAASAuthenticatingFilter is a wrapper around JAASLoginInterceptor and is supposed to return 401 in case of the missing HTTP Authorization header or failed logins. At the moment it leaks SecurityException that JAASLoginInterceptor throws in case of missing (Basic) authorization data which results in the browser reporting 500 instead of popping up the Authenticate window -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4234) JAX-RS JAASAuthenticatingFilter leaks SecurityException
[ https://issues.apache.org/jira/browse/CXF-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250675#comment-13250675 ] Sergey Beryozkin commented on CXF-4234: --- http://svn.apache.org/viewvc?rev=1311716&view=rev http://svn.apache.org/viewvc?rev=1311719&view=rev > JAX-RS JAASAuthenticatingFilter leaks SecurityException > --- > > Key: CXF-4234 > URL: https://issues.apache.org/jira/browse/CXF-4234 > Project: CXF > Issue Type: Bug >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.5.3, 2.6 > > > JAASAuthenticatingFilter is a wrapper around JAASLoginInterceptor and is > supposed to return 401 in case of the missing HTTP Authorization header or > failed logins. At the moment it leaks SecurityException that > JAASLoginInterceptor throws in case of missing (Basic) authorization data > which results in the browser reporting 500 instead of popping up the > Authenticate window -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4234) JAX-RS JAASAuthenticatingFilter leaks SecurityException
[ https://issues.apache.org/jira/browse/CXF-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-4234. --- Resolution: Fixed > JAX-RS JAASAuthenticatingFilter leaks SecurityException > --- > > Key: CXF-4234 > URL: https://issues.apache.org/jira/browse/CXF-4234 > Project: CXF > Issue Type: Bug >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.5.3, 2.6 > > > JAASAuthenticatingFilter is a wrapper around JAASLoginInterceptor and is > supposed to return 401 in case of the missing HTTP Authorization header or > failed logins. At the moment it leaks SecurityException that > JAASLoginInterceptor throws in case of missing (Basic) authorization data > which results in the browser reporting 500 instead of popping up the > Authenticate window -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-4212) Support RBAC in JAX-WS WebServiceContext based on received SAML token
[ https://issues.apache.org/jira/browse/CXF-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff reassigned CXF-4212: - Assignee: Oliver Wulff > Support RBAC in JAX-WS WebServiceContext based on received SAML token > - > > Key: CXF-4212 > URL: https://issues.apache.org/jira/browse/CXF-4212 > Project: CXF > Issue Type: New Feature > Components: JAX-WS Runtime >Affects Versions: 2.5.2 >Reporter: Oliver Wulff >Assignee: Oliver Wulff > > The JAX-WS WebServiceContext API allows to implement role based access > control (RBAC). If the service provider receives a SAML token the role > information can be read out of the SAML token and added to the > WebServiceContext instance for the incoming request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4212) Support RBAC in JAX-WS WebServiceContext based on received SAML token
[ https://issues.apache.org/jira/browse/CXF-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated CXF-4212: -- Fix Version/s: 2.6 > Support RBAC in JAX-WS WebServiceContext based on received SAML token > - > > Key: CXF-4212 > URL: https://issues.apache.org/jira/browse/CXF-4212 > Project: CXF > Issue Type: New Feature > Components: JAX-WS Runtime >Affects Versions: 2.5.2 >Reporter: Oliver Wulff >Assignee: Oliver Wulff > Fix For: 2.6 > > > The JAX-WS WebServiceContext API allows to implement role based access > control (RBAC). If the service provider receives a SAML token the role > information can be read out of the SAML token and added to the > WebServiceContext instance for the incoming request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4212) Support RBAC in JAX-WS WebServiceContext based on received SAML token
[ https://issues.apache.org/jira/browse/CXF-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff resolved CXF-4212. --- Resolution: Fixed > Support RBAC in JAX-WS WebServiceContext based on received SAML token > - > > Key: CXF-4212 > URL: https://issues.apache.org/jira/browse/CXF-4212 > Project: CXF > Issue Type: New Feature > Components: JAX-WS Runtime >Affects Versions: 2.5.2 >Reporter: Oliver Wulff >Assignee: Oliver Wulff > Fix For: 2.5.3, 2.6 > > > The JAX-WS WebServiceContext API allows to implement role based access > control (RBAC). If the service provider receives a SAML token the role > information can be read out of the SAML token and added to the > WebServiceContext instance for the incoming request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4212) Support RBAC in JAX-WS WebServiceContext based on received SAML token
[ https://issues.apache.org/jira/browse/CXF-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated CXF-4212: -- Fix Version/s: 2.5.3 > Support RBAC in JAX-WS WebServiceContext based on received SAML token > - > > Key: CXF-4212 > URL: https://issues.apache.org/jira/browse/CXF-4212 > Project: CXF > Issue Type: New Feature > Components: JAX-WS Runtime >Affects Versions: 2.5.2 >Reporter: Oliver Wulff >Assignee: Oliver Wulff > Fix For: 2.5.3, 2.6 > > > The JAX-WS WebServiceContext API allows to implement role based access > control (RBAC). If the service provider receives a SAML token the role > information can be read out of the SAML token and added to the > WebServiceContext instance for the incoming request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4235) Passing raw xml to a string parameter in the service call
Passing raw xml to a string parameter in the service call - Key: CXF-4235 URL: https://issues.apache.org/jira/browse/CXF-4235 Project: CXF Issue Type: Task Components: Samples Affects Versions: 2.5.2 Environment: Eclipse java 1.6 Reporter: Amar Das Fix For: 2.5.2 I am trying to build a CXF webservice using eclipse. I have a service method String getScore(String param). I want to pass a raw xml to the param. At this moment it gives an exception: Unmarshalling Error: unexpected element (uri:"", local:"aaa"). Expected elements are (none) Please send some sample code to support this. Thanks, Amar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4226) @Description on class level not "inherited"
[
https://issues.apache.org/jira/browse/CXF-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250766#comment-13250766
]
Sergey Beryozkin commented on CXF-4226:
---
My tests show it actually works as long as all the JAX-RS annotations are
grouped at AInterface.
In JAX-RS the annotations are not supposed to be collected from multiple
sources, example, the following won't work:
{code:java}
@Produces("text/xml")
public class ResourceImpl implements Resource {
}
@Path("bar")
public interface Resource {
}
{code}
In the above case, the 'bar' will be lost unless it's pushed up or @Produces is
pushed down.
Do you have ResourceImpl introducing the annotations of its own ?
If you habe AInterface with many implementations then I guess @Description at
the AInterface is not unique enough per every implementation ?
> @Description on class level not "inherited"
> ---
>
> Key: CXF-4226
> URL: https://issues.apache.org/jira/browse/CXF-4226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Priority: Minor
>
> This is really a minor one: if you define a resource via interface
> {code}@Description(title = "My resource")
> interface AResource {
> @GET
> @Description(title = "bar")
> Response foo();
> }{code}
> and then implement it:
> {code}class ResourceImpl implements AResource{
> Response foo(){
> return Response.ok().build();
> }
> }{code}
> Then the generated WADL document will contain the method description ("bar")
> but not the resource level description ("My resource").
> Workaround: annotate concrete implementation classes - this is of course
> rather tedious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4226) @Description on class level not "inherited"
[
https://issues.apache.org/jira/browse/CXF-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250775#comment-13250775
]
Jakub Bocheński commented on CXF-4226:
--
The class-level and method-level annotations are only on the interface.
The implementing class only has some @Context and @PathParam annotations on
fields (otherwise it would defy the point of having an interface).
Like I wrote before: the "bar" from interface method gets picked up, but not
"My resource" from the interface, which is a bit weird.
Actually I only have one implementation, but I don't understand why would this
matter.
If this makes a difference: I register the class passing a concrete
implementation class to JAXRSServerFactoryBean.setResourceClasses() method
(actually I don't see any other way of doing it).
> @Description on class level not "inherited"
> ---
>
> Key: CXF-4226
> URL: https://issues.apache.org/jira/browse/CXF-4226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Priority: Minor
>
> This is really a minor one: if you define a resource via interface
> {code}@Description(title = "My resource")
> interface AResource {
> @GET
> @Description(title = "bar")
> Response foo();
> }{code}
> and then implement it:
> {code}class ResourceImpl implements AResource{
> Response foo(){
> return Response.ok().build();
> }
> }{code}
> Then the generated WADL document will contain the method description ("bar")
> but not the resource level description ("My resource").
> Workaround: annotate concrete implementation classes - this is of course
> rather tedious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4226) @Description on class level not "inherited"
[
https://issues.apache.org/jira/browse/CXF-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Bocheński updated CXF-4226:
-
Description:
This is really a minor one: if you define a resource via interface
{code}@Description(title = "My resource")
interface AResource {
@GET
@Description(title = "bar")
Response foo();
}{code}
and then implement it:
{code}class ResourceImpl implements AResource{
@PathParam("id")
protected int id;
@Context
private HttpHeaders httpHeaders;
@Context
protected UriInfo uriInfo;
public Response foo(){
return Response.ok().build();
}
}{code}
Then the generated WADL document will contain the method description ("bar")
but not the resource level description ("My resource").
Workaround: annotate concrete implementation classes - this is of course rather
tedious.
was:
This is really a minor one: if you define a resource via interface
{code}@Description(title = "My resource")
interface AResource {
@GET
@Description(title = "bar")
Response foo();
}{code}
and then implement it:
{code}class ResourceImpl implements AResource{
Response foo(){
return Response.ok().build();
}
}{code}
Then the generated WADL document will contain the method description ("bar")
but not the resource level description ("My resource").
Workaround: annotate concrete implementation classes - this is of course rather
tedious.
Updated the example with implementation annotations
> @Description on class level not "inherited"
> ---
>
> Key: CXF-4226
> URL: https://issues.apache.org/jira/browse/CXF-4226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Priority: Minor
>
> This is really a minor one: if you define a resource via interface
> {code}@Description(title = "My resource")
> interface AResource {
> @GET
> @Description(title = "bar")
> Response foo();
> }{code}
> and then implement it:
> {code}class ResourceImpl implements AResource{
> @PathParam("id")
> protected int id;
> @Context
> private HttpHeaders httpHeaders;
>
> @Context
> protected UriInfo uriInfo;
> public Response foo(){
> return Response.ok().build();
> }
> }{code}
> Then the generated WADL document will contain the method description ("bar")
> but not the resource level description ("My resource").
> Workaround: annotate concrete implementation classes - this is of course
> rather tedious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CXF-4226) @Description on class level not "inherited"
[
https://issues.apache.org/jira/browse/CXF-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250775#comment-13250775
]
Jakub Bocheński edited comment on CXF-4226 at 4/10/12 4:08 PM:
---
The class-level and method-level annotations are only on the interface.
The implementing class only has some @Context and @PathParam annotations on
fields (otherwise it would defy the point of having an interface).
Like I wrote before: the "bar" from interface method gets picked up, but not
"My resource" from the interface, which is a bit weird.
Actually I only have one implementation, but I don't understand why would this
matter.
If this makes a difference: I register the class passing a concrete
implementation class to JAXRSServerFactoryBean.setResourceClasses() method
(actually I don't see any other way of doing it).
PS. I have enabled static resource resolution - not sure if this makes any
difference.
was (Author: jboch):
The class-level and method-level annotations are only on the interface.
The implementing class only has some @Context and @PathParam annotations on
fields (otherwise it would defy the point of having an interface).
Like I wrote before: the "bar" from interface method gets picked up, but not
"My resource" from the interface, which is a bit weird.
Actually I only have one implementation, but I don't understand why would this
matter.
If this makes a difference: I register the class passing a concrete
implementation class to JAXRSServerFactoryBean.setResourceClasses() method
(actually I don't see any other way of doing it).
> @Description on class level not "inherited"
> ---
>
> Key: CXF-4226
> URL: https://issues.apache.org/jira/browse/CXF-4226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Priority: Minor
>
> This is really a minor one: if you define a resource via interface
> {code}@Description(title = "My resource")
> interface AResource {
> @GET
> @Description(title = "bar")
> Response foo();
> }{code}
> and then implement it:
> {code}class ResourceImpl implements AResource{
> @PathParam("id")
> protected int id;
> @Context
> private HttpHeaders httpHeaders;
>
> @Context
> protected UriInfo uriInfo;
> public Response foo(){
> return Response.ok().build();
> }
> }{code}
> Then the generated WADL document will contain the method description ("bar")
> but not the resource level description ("My resource").
> Workaround: annotate concrete implementation classes - this is of course
> rather tedious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4226) @Description on class level not "inherited"
[
https://issues.apache.org/jira/browse/CXF-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250782#comment-13250782
]
Sergey Beryozkin commented on CXF-4226:
---
Actually, it could be that the snapshot does not contain the fix yet, the
commit to 2.5.3-SNAPSHOT went on 5 April
> @Description on class level not "inherited"
> ---
>
> Key: CXF-4226
> URL: https://issues.apache.org/jira/browse/CXF-4226
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.5.3
>Reporter: Jakub Bocheński
>Priority: Minor
>
> This is really a minor one: if you define a resource via interface
> {code}@Description(title = "My resource")
> interface AResource {
> @GET
> @Description(title = "bar")
> Response foo();
> }{code}
> and then implement it:
> {code}class ResourceImpl implements AResource{
> @PathParam("id")
> protected int id;
> @Context
> private HttpHeaders httpHeaders;
>
> @Context
> protected UriInfo uriInfo;
> public Response foo(){
> return Response.ok().build();
> }
> }{code}
> Then the generated WADL document will contain the method description ("bar")
> but not the resource level description ("My resource").
> Workaround: annotate concrete implementation classes - this is of course
> rather tedious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4114) Better support for backward compatiability (by default)
[ https://issues.apache.org/jira/browse/CXF-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-4114: - Fix Version/s: (was: 2.4.7) (was: 2.5.3) > Better support for backward compatiability (by default) > --- > > Key: CXF-4114 > URL: https://issues.apache.org/jira/browse/CXF-4114 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 2.3.9, 2.4.6, 2.5.2 >Reporter: Rouble > Original Estimate: 120h > Remaining Estimate: 120h > > Consider the situation where a CXF Web Service is released with a certain set > of operations and input/output data beans. Lets call this Web service version > 1.0. Third parties write CXF clients against the CXF Web Service version 1.0 > we'll call these 1.0 CXF clients. > Now, in the next release of the CXF Web Service (say 1.1), one attribute in > one input data bean is removed from the web service. This is widely > considered to be backwards compatible operation. > Any 1.0 CXF clients, will still send that field when communicating with a 1.1 > CXF web service - and the web service will throw an unmarshallexception. A > seemingly innocuous action of removing an attribute from an input data bean > causes the service to stop working for older clients. > Now, there is a workaround in CXF today. By setting > set-jaxb-validation-event-handler to false, you can avoid the JAXB validation > checks. This is done as follows: > address="/v1_0//foo" > implementor="com.example.fooImpl"> > > > > > However, this turns off *all* JAXB validation. That is not desirable for > services. The services should not have to choose between backwards > compatibility and disabling all JAXB validation. > So, this enhancement is requesting for a new property, something like > "set-jaxb-ignore-additional-fields" - which only ignored additional fields > and does not require services to disable all JAXB validation. > Further, this enhancement is requesting that the default for this property be > "true" - so that by default a CXF web service will ignore additional fields > in a SOAP request. This enhancement will take CXF one step closer to > supporting backwards compatibility out of the box - and thus make it more > developer friendly. > Lastly, but importantly, this requirement also applies to clients. In our > example, if the CXF Web Service version 1.1 added a field to an output data > bean, then any 1.0 CXF clients should (by default) not throw an unmarshal > exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4191) RM broken in synchronous Mode
[ https://issues.apache.org/jira/browse/CXF-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-4191: - Fix Version/s: (was: 2.5.3) > RM broken in synchronous Mode > - > > Key: CXF-4191 > URL: https://issues.apache.org/jira/browse/CXF-4191 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4.6 > Environment: CXF 2.4.6, Jdk5 (Jrockit), spring 2.5, maven2, eclipse > 3.7, Win xp >Reporter: Ben Pezzei >Priority: Critical > Labels: Ws-RM, rm > > RM-Setup without a decoupled endpoint (therefore: synchronous modus) > Client is configured with: > includeOffer=true, > SequenceTerminationPolicyType.maxLength=1 > AcknowledgementInterval=0 > Server accepts Offers, wsrm-policy:AcknowledgementInterval=0 > pseudo-Log: > Req 1: createSequence with offer 123 and > acksTo:http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous > Res 1: CreateSequenceResponse with seqid 456 > Req 2: Sequence with Id 456 & lastMessage-flag & actual content > Res 2: Sequence with Id 123 & lastMessage-flag & SequenceAcknowledgement for > Id 456 & actual content > Req 3: TerminateSequence for Id 456 > Res 3: standard rm header > Req 4: SequenceAck for 123 > Req 5: standard rm header > Res 5: standard rm header > Req 6 from Server: terminateSequence for 123 to w3c.org > There is another "feature": When the server PortImpl throws an Exception, > Request/Response goes as follows: > Req 1: createSequence with offer 123 and > acksTo:http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous > Res 1: CreateSequenceResponse with seqid 456 > Req 2: Sequence with Id 456 & lastMessage-flag & actual content > Res 2: Sequence with 456 & lastMessage, Action: NullpointerException, > soap:body contains FaulCode & faultstring > After receiving the response, client throws UnknownSequence: The value of > wsrm:Identifier is not a known Sequence identifier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4132) Support for WS-Topics Concrete and Full expressions
[ https://issues.apache.org/jira/browse/CXF-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-4132: - Fix Version/s: (was: 2.6) > Support for WS-Topics Concrete and Full expressions > --- > > Key: CXF-4132 > URL: https://issues.apache.org/jira/browse/CXF-4132 > Project: CXF > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4209) Server side message redelivery support for WS-RM
[ https://issues.apache.org/jira/browse/CXF-4209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-4209: - Fix Version/s: (was: 2.6) 2.6.1 > Server side message redelivery support for WS-RM > > > Key: CXF-4209 > URL: https://issues.apache.org/jira/browse/CXF-4209 > Project: CXF > Issue Type: New Feature > Components: WS-* Components >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6.1 > > > Currently, when a WS-RM message reaches the RM-Destination at the server side > but not the service itself, there is no mechanism to redeliver this message > to the service. There is also no mechanism for redelivering those persisted > messages at the RM-Destination to the services when the corresponding > destination endpoints are restarted. > A retry mechanism similar to what is available at the RM-Source for message > retransmission can be provided at the RM-Destination to enable message > redelivery. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4097) Remove DynamicImport from jaxb databinding
[ https://issues.apache.org/jira/browse/CXF-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CXF-4097. -- Resolution: Fixed > Remove DynamicImport from jaxb databinding > -- > > Key: CXF-4097 > URL: https://issues.apache.org/jira/browse/CXF-4097 > Project: CXF > Issue Type: Improvement > Components: JAXB Databinding >Affects Versions: 2.5.2 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.6 > > > Currently the JAXB databinding does a dynamic import of com.sun.xml.bind.api > and com.sun.xml.internal.bind.api. > The only reference to it I found was in > org.apache.cxf.jaxb.JAXBContextInitializer.createTypeReference. I think this > can be replaced by a simple new for the class. > Does anyone know why we do the dynamic import? If it is needed I think we > should document it well as it is not obvious to understand. > Are there any test cases I can do to check if my change works? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4101) Minimize use of dynamic import
[ https://issues.apache.org/jira/browse/CXF-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CXF-4101. -- Resolution: Fixed > Minimize use of dynamic import > -- > > Key: CXF-4101 > URL: https://issues.apache.org/jira/browse/CXF-4101 > Project: CXF > Issue Type: Improvement > Components: Core, OSGi >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 2.6 > > > Currently we have a lot of dynamic import statements in api. I think most of > them are not necessary and can be replaced by normal imports. > There are also some dynamic imports in jaxb as it needs to load a class at > runtime. I propose to move that functionality to api so most classloading > stuff happens there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
