Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/309
I'm not sure if users actually have ever tried to extend these classes, we
can ask at the CXF users for example if someone has tried it...Can you please
try to do another PR but based on updating
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/309
Thanks for this effort. Can you consider modifying the existing
interceptors to make them charset-aware instead of creating a new set of
interceptors ? In reality some users will continue using
Github user sberyozkin commented on a diff in the pull request:
https://github.com/apache/cxf/pull/301#discussion_r130992343
--- Diff:
rt/rs/sse/src/main/java/org/apache/cxf/jaxrs/sse/OutboundSseEventImpl.java ---
@@ -24,24 +24,24 @@
import javax.ws.rs.core.MediaType
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/294
Thanks, can you please rewrite the test code with the Java 7 in mind - CXF
3.1.x should compile with Java 7
---
If your project is set up for it, you can reply to this email and have your
reply
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/292
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/286
Thanks, 3.1.x build is due today hence I decided to fix it fast...
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/286
Hi, thanks for the patch, sorry but I already committed a fix, few secs
before you submitted your own one,
http://git-wip-us.apache.org/repos/asf/cxf/commit/88f8ce6e, sorry about it,
hope you
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf-fediz/pull/19
UriInfo.resolve and UriInfo.relativize are also available as apparently
URI.normalize does not always work right, but yeah, I guess in simple cases it
should do.
---
If your project is set up
Github user sberyozkin commented on a diff in the pull request:
https://github.com/apache/cxf/pull/273#discussion_r117440452
--- Diff:
rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/JPAOAuthDataProvider.java
---
@@ -213,6 +221,25
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/273
Hi, thanks for the patch. Can you please consider locking at the
AbstractOAuthDataProvider level instead, so that all its extensions (JPA2,
JCache, Ehcache and future ones like Mongo-based) can
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/272
Actually, it looks OK, I was concerned that a 'REST' will be printed for
every REST request in the default case :-). Looks good to me.
---
If your project is set up for it, you can reply
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/272
Hi David, I'd rather restore the ability to pass a custom logging category.
Service qname can be configured for jaxrs endpoingts too, so this SOAP and REST
markers will just cause the confusion
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/270
Hi Andy, this fix looks good, please go ahead with the merge, thanks
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/267
Thanks, ended just adding them directly to the returned lists
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/267
Ouch, thanks for spotting it. To be honest I'd rather get rid of the
duplicates (in, out, out fault interceptors) at the
AbstractSpringComponentScanServer
---
If your project is set up for it, you
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/264
Never mind, spring boot version was already set to 1.5.2.RELEASE on master,
I'll merge javadocs updates
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/265
I just checked, the in fault interceptors are not run (try to throw a Fault
from the in interceptor) but the in interceptors.handleFault method is called.
Ideally we'd not have the option to set
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/264
Can you please create another PR related to JavaDocs and SpringBoot version
update, thanks
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/265
Thanks, does CXF run in-fault interceptors on the server side ? May be I'm
wrong, need to double check, I thought they were only run on the client side.
---
If your project is set up for it, you
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/264
I agree, I'd just override createJaxrsServer, if AppPath is there then
complete it otherwise delegate to the superclass, I can take care of it while
working on your patch
---
If your project
Github user sberyozkin commented on a diff in the pull request:
https://github.com/apache/cxf/pull/253#discussion_r109885798
--- Diff:
rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java
---
@@ -1167,10 +1161,12 @@ public static void
Github user sberyozkin commented on a diff in the pull request:
https://github.com/apache/cxf/pull/253#discussion_r109372768
--- Diff:
rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java
---
@@ -1167,10 +1161,12 @@ public static void
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/247
Hi Dennis, is it related to the client proxy thing ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/commit/66f652cca276fba8395496454e870cfb82439549#commitcomment-21066333
In
rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/HttpServletRequestFilter.java:
In
rt/frontend/jaxrs/src/main
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/236
Thanks for the patch
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/238
I've already back merged it into 3.1.11-SNAPSHOT
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/238
Thanks for the patch, I've added a 'jaxb' prefix to the property name given
that using JAXB can be optional and other strategies can be used
---
If your project is set up for it, you can reply
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/233
I've opened https://issues.apache.org/jira/browse/CXF-7237 to get this
issue tracked and be more visible, thanks
---
If your project is set up for it, you can reply to this email and have your
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/233
In other words, given that it was confirmed CXF starters can now work with
1.5.x, I think that we should only upgrade to 1.5.x if we start using 1.5.x
features inside CXF starters - to make sure CXF
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/233
See my comments to #232. The actual version upgrade does not change
anything in CXF but a change a new major SprongBoot dep. This is not a bad idea
in itself - but will we break 1.4.x SpringBoot
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/232
That problem was fixed earlier, I don't get how upgrading the version to
1.5.1 adds anything to what was already fixed
---
If your project is set up for it, you can reply to this email and have
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/232
Why CXF starters depending on 1.4.3 is problematic when they are used with
1.5.1 containers ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/229
Can you please update this patch so that only the proposed changes are
visible ? Looks like some format-related changes made into it too
---
If your project is set up for it, you can reply
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/211
Thanks for the patch, note it contains an older fix which I've already
applied on your behalf earlier. I did a minor tweak and added a utility method
to JAXRSUtils to keep the set of streaming
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/203
Thanks for the patch - note I had to set this new property to 'true' by
default - to preserve the original filter behaviour with respect to how it
authenticates when acquiring the token
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/194
Johannes, please start from the latest email discussion and proceed from
there, thanks. Lets put all this XML schema + Bean Validation on hold for now
---
If your project is set up for it, you can
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/183
While I appreciate this quality patch I'd like to say that the way the
spring_boot_scan server and client applications are started is really off topic
for CXF-7093, however as I noted I can def live
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/183
John, does the demo work without a version qualifier of the final jar, when
it is started with a "java -jar" ? Also as a side note I'm not convinced
-Pserver does not make sense for the s
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/182
oops :-), Sorry Andriy :-)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/182
Hi Guys, I've just applied, double checked that the super class creates a
new set so that should be safe, Andriy, hope you are OK, we can always tweak
few things in the source too :-).
---
If your
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/182
Hey Andriy, IMHO it is ready to be merged, re your last comment,
super.getTypes() returns a new set, John just pushed this code to the
superclass. thanks
---
If your project is set up for it, you
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/182
Yeah, sorry for being so ignorant :-), realized after I made this comment.
+1 from my side to this patch, thanks
---
If your project is set up for it, you can reply to this email and have your
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/182
Well I found your comment about CI confusing, not sure what it was to do
with our discussion given that this PR was not applied to the CXF source
---
If your project is set up for it, you can reply
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/182
Sorry, would you still like this patch applied, did you mean to reply to
https://github.com/apache/cxf/pull/181 with your last comment ?
---
If your project is set up for it, you can reply
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/182
I see, IMHO this should be OK, as #load checks if it is an empty app and
proceeds accordingly.
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/182
Why is default application needed ? thanks
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/commit/66f652cca276fba8395496454e870cfb82439549#commitcomment-19482592
Hi, thanks, has just been fixed. Please use getParameterNames or Map for now
---
If your project is set up for it, you can reply
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/170
I've applied the patch with the minor modifications, thanks. I've only made
StringBuilder instantiation optional, and kept the original message format. I'm
open though to add 'Value of' - how does
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/170
Unfortunately we can not introduce Spring dependencies into this code. The
simplest option to customize is to register a custom ValidationExceptionMapper
---
If your project is set up for it, you
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/151
Well at the moment the CXF code splits by "=". This can be rewritten to
check for the first "=" instead and it will be faster and will work for quoted
and unquoted file names
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/154
Hi Andriy
That spec statement is many years old, coming form 1.1 or earlier, before
ApplicationPath was introduced (AFAIK) thus one may say well that statement
does not apply
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/149
Hi, re "Would it be OK if I modified the job to have a longer history?" -
sounds reasonable, Dan, what do you think ?
---
If your project is set up for it, you can reply to this email and
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/151
Thanks for the patch. Would it be possible to avoid bringing in a new
dependency only to make it easier to deal with this case ?
---
If your project is set up for it, you can reply to this email
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/commit/ed9298066428c0dfc4590a556876d696a4ba13c0#commitcomment-18226649
Thanks for giving it a try. Lets discuss the ideas on how to improve this
demo on CXF lists, cheers
---
If your project is set
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/commit/ed9298066428c0dfc4590a556876d696a4ba13c0#commitcomment-18192484
Hmm,
https://repository.apache.org/content/repositories/snapshots/org/apache/cxf/
does not show it, though it was there few days
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/130#issuecomment-211834956
See also http://git-wip-us.apache.org/repos/asf/cxf/commit/2f881786, thanks
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/130#issuecomment-211572888
Thanks for the patch. I guess the validation code will need to be tightened
a bit to support the case where the expiresAt is less than the current time. I
can take care
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/81#issuecomment-188252113
Hi - did not see your pull request before applying my own fix - hope you
are ok with the fix applied, thanks
---
If your project is set up for it, you can reply
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/111#issuecomment-187119639
Thanks for the patch, however I believe I clarified why the code is written
the way it is now in
https://issues.apache.org/jira/secure/EditComment!default.jspa?id
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/commit/d8edf3161f199d9c2fe3cb8314f6e98782bf22c5#commitcomment-14475026
Done
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/commit/d8edf3161f199d9c2fe3cb8314f6e98782bf22c5#commitcomment-14468992
Sure, was just a quick replacement of the map type. Will update shortly.
The whole thread proxy storage code will need
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/89#issuecomment-151457709
emlun, how did you have a 'charset=' created, do you use some existing REST
client that does it ?
---
If your project is set up for it, you can reply to this email
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/89#issuecomment-151457508
Sorry, I meant ISO-8859-1, my fault. As far as the actual defaulting is
concerned, I've no strong opinion here, the older code was interpreting the
absence
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/89#issuecomment-151290264
Hi emlun - sure I'll bear that in mind when merging your next patch, hi Aki
- I think there was a code there already defaulting to UTF-8, but if you think
something may
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/95#issuecomment-146523788
Thanks for a patch
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/89#issuecomment-146677926
Sure, I'll explain. I did not like the actual test name and I thought it
was not a very useful test as it was only 'asserting' that the given line runs
- hence I added
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/89#issuecomment-146145971
FYI, http://git-wip-us.apache.org/repos/asf/cxf/commit/59b87cad, I did not
apply the patch directly, as I renamed the tests. Please close this request
yourself. Thanks
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/59#issuecomment-84168963
Patch has been applied, thanks
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/49#issuecomment-69081994
Thanks for this effort. At the moment I'm not certain we need the advanced
optimization like this one.
Where exactly is a bottleneck ? Perhaps it can be resolved
Github user sberyozkin commented on the pull request:
https://github.com/apache/cxf/pull/45#issuecomment-67645463
Hi, thanks for the patch, I've applied it with minor modifications (keep
the sync block on if a disableAddressProperties is set to a legacy false value)
Cheers
70 matches
Mail list logo
