Re: New Java 9 master

[Christian Schneider]

I dont think we can already predict when users move to Java 9.
So creating a Java 9 only branch at this time means we have to maintain two
main branches over a long time.

What is the rationale behind a Java 9 only branch compared to being Java 9
and Java 8 compatible on master?

Christian

2017-11-15 12:47 GMT+01:00 Sergey Beryozkin :

> Hi
>
> Should we open a new Java 9 only master soon enough ?
>
> Thanks, Sergey
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com

Re: New Java 9 master

[Freeman Fang]

+1

If next CXF major release(3.3 or 4.0) are not going to support JDK8 anymore, 
it’s about the time to create master branch which is for Java9(and the 
successor JDK version which is not very far away). And this also would be easy 
for us to adjust CXF to use the jigsaw module eventually, like to add 
module-info.java  to see how is it going on there.

Best Regards
－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat



> On Nov 16, 2017, at 1:03 PM, Andy McCright  
> wrote:
> 
> Hi Sergey,
> 
> I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
> limited support release.  According to Oracle's support strategy [1], Java
> 9 will only be supported until March 2018, then they will be releasing Java
> 10 (aka 18.3) which also will have a short shelf-life.  The next long-term
> support release is 18.9 which releases in September.  We'll probably want
> the new Java 9 master branch to work with 18.3 as well, then maybe consider
> a new master branch for 18.9 some time next year. What do you think?
> 
> Thanks,
> Andy
> 
> [1] http://www.oracle.com/technetwork/java/eol-135779.html
> 
> On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
> wrote:
> 
>> Hi
>> 
>> Should we open a new Java 9 only master soon enough ?
>> 
>> Thanks, Sergey
>> 

Re: New Java 9 master

[Andy McCright]

Hi Sergey,

I'm in favor of the idea.  One thing worth noting is that Java 9 is a very
limited support release.  According to Oracle's support strategy [1], Java
9 will only be supported until March 2018, then they will be releasing Java
10 (aka 18.3) which also will have a short shelf-life.  The next long-term
support release is 18.9 which releases in September.  We'll probably want
the new Java 9 master branch to work with 18.3 as well, then maybe consider
a new master branch for 18.9 some time next year. What do you think?

Thanks,
Andy

[1] http://www.oracle.com/technetwork/java/eol-135779.html

On Wed, Nov 15, 2017 at 5:47 AM, Sergey Beryozkin 
wrote:

> Hi
>
> Should we open a new Java 9 only master soon enough ?
>
> Thanks, Sergey
>

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Andriy Redko]

Hey Sergey,

That would be ideal I think (move RxJava into separate module). RxJava2 and
RxJava are quite different frameworks, some people just stuck with RxJava so
we could support them there. Thanks.

Best Regards,
Andriy Redko

JDA> What about just leaving the old RxJava code in a module by itself (when I
JDA> was looking recently, it didn't make much sense to see both RxJava and
JDA> RxJava2 in one module).

JDA> On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin 
JDA> wrote:

>> Hi

>> cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2
>> code. It supports returning RxJava2 Flowable and Observable on the
>> server and accepting it on the client, and the same for the (old) RxJava
>> Observable...

>> While even the (old) RxJava code is very new for CXF, the reality is
>> that RxJava has been around for a while now and with RxJava2 embracing
>> org.reactivestreams, it's hard to see CXF users preferring to start with
>> the (old) RxJava.

>> The other minor problem is that cxf-rt-rs-extension-rx has optional
>> RxJava and RxJava2 deps to be able to ship the relevant code in the same
>> module and splitting it into 2 modules will be too much at this point.

>> I suggest that unless some users confirm (I CC to the users) that they
>> need to use the (old) RxJava code, then we just remove it and make
>> things much simpler...

>> Thanks, Sergey

Re: Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

Hi,

Indeed, creating a new module specifically for RxJava is technically 
clean, but creating it for a code which no one will probably use and 
also adding one module to the large number of CXF modules, with only 2/3 
Java files :-) is a bit problematic...


I guess I can keep it as is in 3.2.x but remove it once a new master 
opens...


Thanks, Sergey
On 15/11/17 16:04, John D. Ament wrote:

What about just leaving the old RxJava code in a module by itself (when I
was looking recently, it didn't make much sense to see both RxJava and
RxJava2 in one module).

On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin 
wrote:


Hi

cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2
code. It supports returning RxJava2 Flowable and Observable on the
server and accepting it on the client, and the same for the (old) RxJava
Observable...

While even the (old) RxJava code is very new for CXF, the reality is
that RxJava has been around for a while now and with RxJava2 embracing
org.reactivestreams, it's hard to see CXF users preferring to start with
the (old) RxJava.

The other minor problem is that cxf-rt-rs-extension-rx has optional
RxJava and RxJava2 deps to be able to ship the relevant code in the same
module and splitting it into 2 modules will be too much at this point.

I suggest that unless some users confirm (I CC to the users) that they
need to use the (old) RxJava code, then we just remove it and make
things much simpler...

Thanks, Sergey

Re: Remove obsolete RxJava code and keep RxJava2 only one

[John D. Ament]

What about just leaving the old RxJava code in a module by itself (when I
was looking recently, it didn't make much sense to see both RxJava and
RxJava2 in one module).

On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin 
wrote:

> Hi
>
> cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2
> code. It supports returning RxJava2 Flowable and Observable on the
> server and accepting it on the client, and the same for the (old) RxJava
> Observable...
>
> While even the (old) RxJava code is very new for CXF, the reality is
> that RxJava has been around for a while now and with RxJava2 embracing
> org.reactivestreams, it's hard to see CXF users preferring to start with
> the (old) RxJava.
>
> The other minor problem is that cxf-rt-rs-extension-rx has optional
> RxJava and RxJava2 deps to be able to ship the relevant code in the same
> module and splitting it into 2 modules will be too much at this point.
>
> I suggest that unless some users confirm (I CC to the users) that they
> need to use the (old) RxJava code, then we just remove it and make
> things much simpler...
>
> Thanks, Sergey
>

Remove obsolete RxJava code and keep RxJava2 only one

[Sergey Beryozkin]

Hi

cxf-rt-rs-extension-rx ships the code for both (old) RxJava and RxJava2 
code. It supports returning RxJava2 Flowable and Observable on the 
server and accepting it on the client, and the same for the (old) RxJava

Observable...

While even the (old) RxJava code is very new for CXF, the reality is 
that RxJava has been around for a while now and with RxJava2 embracing 
org.reactivestreams, it's hard to see CXF users preferring to start with 
the (old) RxJava.


The other minor problem is that cxf-rt-rs-extension-rx has optional 
RxJava and RxJava2 deps to be able to ship the relevant code in the same 
module and splitting it into 2 modules will be too much at this point.


I suggest that unless some users confirm (I CC to the users) that they 
need to use the (old) RxJava code, then we just remove it and make 
things much simpler...


Thanks, Sergey

[GitHub] sberyozkin commented on issue #339: CXF-7544: Support @Context-based injection into proxied CDI beans

[GitBox]

sberyozkin commented on issue #339: CXF-7544: Support @Context-based injection 
into proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344625021
 
 
   Not my fault this PR has been closed :-)


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] reta closed pull request #339: CXF-7544: Support @Context-based injection into proxied CDI beans

[GitBox]

reta closed pull request #339: CXF-7544: Support @Context-based injection into 
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java 
b/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
index c32e6690981..ac54da90535 100644
--- a/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
+++ b/integration/cdi/src/main/java/org/apache/cxf/cdi/CdiClassUnwrapper.java
@@ -22,8 +22,18 @@
 
 import org.apache.cxf.common.util.ClassUnwrapper;
 
+/**
+ * Unwraps the CDI proxy classes into real classes.
+ */
 class CdiClassUnwrapper implements ClassUnwrapper {
-private static final Pattern PROXY_PATTERN = 
Pattern.compile(".+\\$\\$.+Proxy");
+/**
+ * Known proxy patterns for OWB and Weld:
+ * 
+ *  Xxx$$OwbNormalScopeProxy0
+ *  Xxx$Proxy$_$$_WeldClientProxy
+ *  
+ */
+private static final Pattern PROXY_PATTERN = 
Pattern.compile(".+\\$\\$.+Proxy\\d*");
 
 CdiClassUnwrapper() {
 
diff --git 
a/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
 
b/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
index ce23e1a924c..823ae5e8291 100644
--- 
a/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
+++ 
b/integration/cdi/src/main/java/org/apache/cxf/cdi/JAXRSCdiResourceExtension.java
@@ -27,6 +27,7 @@
 import java.util.ServiceLoader;
 import java.util.Set;
 
+import javax.enterprise.context.ApplicationScoped;
 import javax.enterprise.context.spi.CreationalContext;
 import javax.enterprise.event.Observes;
 import javax.enterprise.inject.spi.AfterBeanDiscovery;
@@ -38,10 +39,13 @@
 import javax.enterprise.inject.spi.Extension;
 import javax.enterprise.inject.spi.InjectionTarget;
 import javax.enterprise.inject.spi.ProcessBean;
+import javax.enterprise.inject.spi.ProcessInjectionTarget;
 import javax.enterprise.inject.spi.ProcessProducerField;
 import javax.enterprise.inject.spi.ProcessProducerMethod;
 import javax.ws.rs.ApplicationPath;
 import javax.ws.rs.Path;
+import javax.ws.rs.container.ContainerRequestFilter;
+import javax.ws.rs.container.ContainerResponseFilter;
 import javax.ws.rs.core.Application;
 import javax.ws.rs.ext.MessageBodyReader;
 import javax.ws.rs.ext.MessageBodyWriter;
@@ -51,6 +55,7 @@
 import org.apache.cxf.bus.extension.ExtensionManagerBus;
 import org.apache.cxf.cdi.event.DisposableCreationalContext;
 import org.apache.cxf.cdi.extension.JAXRSServerFactoryCustomizationExtension;
+import org.apache.cxf.cdi.inject.ContextInjectionTarget;
 import org.apache.cxf.feature.Feature;
 import org.apache.cxf.jaxrs.JAXRSServerFactoryBean;
 import org.apache.cxf.jaxrs.provider.ServerConfigurableFactory;
@@ -122,6 +127,21 @@ public void addResourceProvider(final CdiResourceProvider 
other) {
 }
 }
 
+public  void processInjectionTarget(@Observes final 
ProcessInjectionTarget target, 
+final BeanManager beanManager) {
+
+final InjectionTarget injectionTarget = target.getInjectionTarget();
+final AnnotatedType type = target.getAnnotatedType();
+
+// The beans annotated with @ApplicationScoped will be very likely 
proxified.
+boolean isApplicationScoped = 
type.isAnnotationPresent(ApplicationScoped.class);
+if (isApplicationScoped && isProvider(type)) {
+// Limit the scope to providers for now
+final InjectionTarget contextual = new 
ContextInjectionTarget<>(injectionTarget, type.getJavaClass());
+target.setInjectionTarget(contextual);
+}
+}
+
 public  void collect(@Observes final ProcessProducerField< T, X > 
event) {
 final Type baseType = event.getAnnotatedProducerField().getBaseType();
 processProducer(event, baseType);
@@ -421,4 +441,16 @@ private void customize(final BeanManager beanManager, 
final JAXRSServerFactoryBe
 }
 }
 
+/**
+ * Tries to detect of a particular annotated type corresponds to provider
+ * @param type annotated type 
+ * @return "true" if annotated type corresponds to provider, "false" 
otherwise
+ */
+private boolean isProvider(final AnnotatedType type) {
+return type.isAnnotationPresent(Provider.class) 
+|| 
ContainerRequestFilter.class.isAssignableFrom(type.getJavaClass()) 
+|| 
ContainerResponseFilter.class.isAssignableFrom(type.getJavaClass()) 
+|| MessageBodyWriter.class.isAssignableFrom(type.getJavaClass()) 
+|| MessageBodyReader.class.isAssignableFrom(type.getJavaClass());
+}
 }
diff --git 

[GitHub] reta commented on issue #339: CXF-7544: Support @Context-based injection into proxied CDI beans

[GitBox]

reta commented on issue #339: CXF-7544: Support @Context-based injection into 
proxied CDI beans
URL: https://github.com/apache/cxf/pull/339#issuecomment-344591904
 
 
   Better solution is required, closing 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

New Java 9 master

[Sergey Beryozkin]

Hi

Should we open a new Java 9 only master soon enough ?

Thanks, Sergey

[GitHub] forsthofer commented on a change in pull request #340: [CXF-7562] correction for truncated flag

[GitBox]

forsthofer commented on a change in pull request #340: [CXF-7562] correction 
for truncated flag
URL: https://github.com/apache/cxf/pull/340#discussion_r151102002
 
 

 ##
 File path: 
rt/features/logging/src/main/java/org/apache/cxf/ext/logging/LoggingOutInterceptor.java
 ##
 @@ -82,7 +82,10 @@ private OutputStream createCachingOut(Message message, 
final OutputStream os, Ca
 newOut.setThreshold(threshold);
 }
 if (limit > 0) {
-newOut.setCacheLimit(limit);
+// make the limit for the cache greater than the limit for the 
truncated payload in the log event, 
+// this is necessary for finding out that the payload was 
truncated 
+//(see boolean isTruncated = cos.size() > limit && limit != -1;)  
in method copyPayload
+newOut.setCacheLimit(limit + 1);
 
 Review comment:
   instead of just setting the limit to 'limit +1' one should check whether the 
limit == Integer.MAX_VALUE and if this is the case just use Integer.MAX_VALUE


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services