[GitHub] rmannibucau commented on issue #482: [CXF-7926] Initial MP Rest Client 1.2 impl
rmannibucau commented on issue #482: [CXF-7926] Initial MP Rest Client 1.2 impl URL: https://github.com/apache/cxf/pull/482#issuecomment-451357956 Well there is a ticket for that at cdi level (isnt it stupid technically? ;)). But the fix can be: provide the "internal most nested impl" as a specific bean and inject this "impl bean" to the factory :). You can even do the impl as an interceptor (no more invocation handler at all) for that case with no impl and just use the factory with a bean returning null as base. 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
Re: GraphQL Project?
Awesome! Thanks for the feedback. Regarding the API - the intent is be able to use a "code-first" approach - i.e. write your object model in Java using annotations similar to JAXB/JSON-B/etc. as necessary - write your business logic (CRUD operations) similar to JAX-RS resource methods. That would allow the user to generate a schema file. Most of the GraphQL Java implementations that I have seen have a "schema-first" approach which leads to a lot of duplication of effort. Regarding the underlying implementation (whether to use graphql-java or not), that question was asked in the last MP project meeting, and we decided that it would be considered an implementation detail. My opinion would be to use graphql-java as a starting point, and only write something from scratch if we find major limitations with it. As far as timeline goes, I think it will be a while before we start work on the implementation. The MP project is just getting started, and I suspect it will take a while to work out the spec work. Thanks again, Andy On Thu, Jan 3, 2019 at 7:21 PM Andriy Redko wrote: > Hey Andy, > > Certainly +1, I think CXF would be a great place to host HTTP-based > MP GraphQL implementation. I am wondering (probably related to Romain's > 2nd point) if the intention is to implement the specification from scratch > or pull in graphql-java? In any case, I think it would be great addition to > CXF, count me in. > > Best Regards, > Andriy Redko > > Thursday, January 3, 2019, 5:49:34 PM, you wrote: > > RMB> +1 > > RMB> Two small side notes: > > RMB> 1. If cxf is not the right "home", geronimo would definitively be ( > RMB> http://geronimo.apache.org/microprofile/ to be concrete) > RMB> 2. From my past experience having a graphql parser API (body reader > for > RMB> jaxrs/mp) is the most important feature, everything else is mainly > the link > RMB> to the backend and highly depends impl choices and the abstraction a > RMB> framework gives is often more an issue (N+1 queries to cite one > obvious > RMB> common problem) than a solution even if tempting > > RMB> Le jeu. 3 janv. 2019 23:29, Andy McCright < > j.andrew.mccri...@gmail.com> a > RMB> écrit : > > >> Hi All, > > >> I've been involved in an effort to create a MicroProfile GraphQL project > >> that would provide a Java framework for building and deploying GraphQL > >> apps. The API would look similar to JAX-RS (i.e. @Query annotations > >> instead of @GET, etc.). > > >> We have a draft project proposal available here: > > >> > https://docs.google.com/document/d/1prwMGxgr0cI5yx4lrvMET5x6rD-CQ1y7XuS1PCegE4A/edit# > > >> Would this be something that we could implement in a new CXF module? > And > >> would anybody on this list be interested in participating in the MP spec > >> project? > > >> Thanks in advance! > > >> Andy > > >> PS - we have a spec project meeting tomorrow at 10:30am US Eastern time. > >> Meeting minutes (and a link to the webex) is available here: > > >> > https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit# > > >
Re: GraphQL Project?
Hey Andy, Certainly +1, I think CXF would be a great place to host HTTP-based MP GraphQL implementation. I am wondering (probably related to Romain's 2nd point) if the intention is to implement the specification from scratch or pull in graphql-java? In any case, I think it would be great addition to CXF, count me in. Best Regards, Andriy Redko Thursday, January 3, 2019, 5:49:34 PM, you wrote: RMB> +1 RMB> Two small side notes: RMB> 1. If cxf is not the right "home", geronimo would definitively be ( RMB> http://geronimo.apache.org/microprofile/ to be concrete) RMB> 2. From my past experience having a graphql parser API (body reader for RMB> jaxrs/mp) is the most important feature, everything else is mainly the link RMB> to the backend and highly depends impl choices and the abstraction a RMB> framework gives is often more an issue (N+1 queries to cite one obvious RMB> common problem) than a solution even if tempting RMB> Le jeu. 3 janv. 2019 23:29, Andy McCright a RMB> écrit : >> Hi All, >> I've been involved in an effort to create a MicroProfile GraphQL project >> that would provide a Java framework for building and deploying GraphQL >> apps. The API would look similar to JAX-RS (i.e. @Query annotations >> instead of @GET, etc.). >> We have a draft project proposal available here: >> https://docs.google.com/document/d/1prwMGxgr0cI5yx4lrvMET5x6rD-CQ1y7XuS1PCegE4A/edit# >> Would this be something that we could implement in a new CXF module? And >> would anybody on this list be interested in participating in the MP spec >> project? >> Thanks in advance! >> Andy >> PS - we have a spec project meeting tomorrow at 10:30am US Eastern time. >> Meeting minutes (and a link to the webex) is available here: >> https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit#
[GitHub] amarkevich closed pull request #489: Update maven-processor-plugin; move version to the parent pom
amarkevich closed pull request #489: Update maven-processor-plugin; move version to the parent pom URL: https://github.com/apache/cxf/pull/489 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/parent/pom.xml b/parent/pom.xml index 541ca5c28f5..0f03fa7a48f 100644 --- a/parent/pom.xml +++ b/parent/pom.xml @@ -556,6 +556,11 @@ + +org.bsc.maven +maven-processor-plugin +3.3.3 + diff --git a/rt/rs/security/oauth-parent/oauth2/pom.xml b/rt/rs/security/oauth-parent/oauth2/pom.xml index 45a8000d6da..08532d6cc29 100644 --- a/rt/rs/security/oauth-parent/oauth2/pom.xml +++ b/rt/rs/security/oauth-parent/oauth2/pom.xml @@ -191,7 +191,6 @@ org.bsc.maven maven-processor-plugin -3.2.0 process diff --git a/rt/rs/security/sso/oidc/pom.xml b/rt/rs/security/sso/oidc/pom.xml index 835a1bbef8b..85605c430bb 100644 --- a/rt/rs/security/sso/oidc/pom.xml +++ b/rt/rs/security/sso/oidc/pom.xml @@ -159,7 +159,6 @@ org.bsc.maven maven-processor-plugin -3.2.0 process 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] amarkevich closed pull request #490: cxf-rt-transports-udp: minor code improvements to improve test stability
amarkevich closed pull request #490: cxf-rt-transports-udp: minor code
improvements to improve test stability
URL: https://github.com/apache/cxf/pull/490
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/rt/transports/udp/src/main/java/org/apache/cxf/transport/udp/UDPConduit.java
b/rt/transports/udp/src/main/java/org/apache/cxf/transport/udp/UDPConduit.java
index edeacd2822c..3805c37f47b 100644
---
a/rt/transports/udp/src/main/java/org/apache/cxf/transport/udp/UDPConduit.java
+++
b/rt/transports/udp/src/main/java/org/apache/cxf/transport/udp/UDPConduit.java
@@ -114,11 +114,7 @@ private void dataReceived(Message message, IoBuffer buf,
boolean async, boolean
if (queue == null) {
queue = queuem.getAutomaticWorkQueue();
}
-queue.execute(new Runnable() {
-public void run() {
-incomingObserver.onMessage(inMessage);
-}
-});
+queue.execute(() -> incomingObserver.onMessage(inMessage));
} else {
incomingObserver.onMessage(inMessage);
if (!message.getExchange().isSynchronous() || multi) {
@@ -194,17 +190,13 @@ public void prepare(final Message message) throws
IOException {
int port = Integer.parseInt(s);
sendViaBroadcast(message, null, port);
} else {
-InetSocketAddress isa = null;
-String hp = "";
-
-isa = new InetSocketAddress(uri.getHost(), uri.getPort());
-hp = uri.getHost() + ":" + uri.getPort();
-
+final InetSocketAddress isa = new
InetSocketAddress(uri.getHost(), uri.getPort());
if (isa.getAddress().isMulticastAddress()) {
sendViaBroadcast(message, isa, isa.getPort());
return;
}
+final String hp = uri.getHost() + ':' + uri.getPort();
Queue q = connections.get(hp);
ConnectFuture connFuture = null;
if (q != null) {
@@ -217,9 +209,9 @@ public void prepare(final Message message) throws
IOException {
((DatagramSessionConfig)connFuture.getSession().getConfig()).setReceiveBufferSize(64
* 1024);
}
connFuture.getSession().setAttribute(CXF_MESSAGE_ATTR,
message);
-message.setContent(OutputStream.class, new
UDPConduitOutputStream(connector, connFuture, message));
+message.setContent(OutputStream.class, new
UDPConduitOutputStream(connFuture));
message.getExchange().put(ConnectFuture.class, connFuture);
-message.getExchange().put(HOST_PORT, uri.getHost() + ":" +
uri.getPort());
+message.getExchange().put(HOST_PORT, hp);
}
} catch (Exception ex) {
throw new IOException(ex);
@@ -340,19 +332,13 @@ public void flush() throws IOException {
}
}
-public class UDPConduitOutputStream extends OutputStream {
+static class UDPConduitOutputStream extends OutputStream {
final ConnectFuture future;
-final NioDatagramConnector connector;
-final Message message;
IoBuffer buffer = IoBuffer.allocate(64 * 1024 - 42); //max size
boolean closed;
-public UDPConduitOutputStream(NioDatagramConnector connector,
- ConnectFuture connFuture,
- Message m) {
-this.connector = connector;
+UDPConduitOutputStream(ConnectFuture connFuture) {
this.future = connFuture;
-this.message = m;
}
public void write(int b) throws IOException {
diff --git
a/rt/transports/udp/src/main/java/org/apache/cxf/transport/udp/UDPDestination.java
b/rt/transports/udp/src/main/java/org/apache/cxf/transport/udp/UDPDestination.java
index c5b8996fca2..d3e22ac4a65 100644
---
a/rt/transports/udp/src/main/java/org/apache/cxf/transport/udp/UDPDestination.java
+++
b/rt/transports/udp/src/main/java/org/apache/cxf/transport/udp/UDPDestination.java
@@ -98,22 +98,14 @@ public void close() throws IOException {
}
};
-UDPConnectionInfo info = new UDPConnectionInfo(null,
- out,
- new
ByteArrayInputStream(bytes, 0, p.getLength()));
-
final MessageImpl m = new MessageImpl();
final Exchange exchange =
[GitHub] andymc12 commented on issue #482: [CXF-7926] Initial MP Rest Client 1.2 impl
andymc12 commented on issue #482: [CXF-7926] Initial MP Rest Client 1.2 impl URL: https://github.com/apache/cxf/pull/482#issuecomment-451303175 Happy New Year @rmannibucau! And thanks - that helps a lot! I've updated the code to use CDI AnnotatedTypes which should address your first concern. As for the second concern, I agree that the InterceptionFactory should help, but I think that it will not work (at least for wrapping the MP Rest Client instance) because it would be creating a dynamic proxy to wrap another dynamic proxy. I'm not sure if that is possible - and I think that it falls under the [unproxyable category](http://docs.jboss.org/cdi/spec/2.0-PRD/cdi-spec.html#unproxyable). 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
Re: GraphQL Project?
+1 Two small side notes: 1. If cxf is not the right "home", geronimo would definitively be ( http://geronimo.apache.org/microprofile/ to be concrete) 2. From my past experience having a graphql parser API (body reader for jaxrs/mp) is the most important feature, everything else is mainly the link to the backend and highly depends impl choices and the abstraction a framework gives is often more an issue (N+1 queries to cite one obvious common problem) than a solution even if tempting Le jeu. 3 janv. 2019 23:29, Andy McCright a écrit : > Hi All, > > I've been involved in an effort to create a MicroProfile GraphQL project > that would provide a Java framework for building and deploying GraphQL > apps. The API would look similar to JAX-RS (i.e. @Query annotations > instead of @GET, etc.). > > We have a draft project proposal available here: > > https://docs.google.com/document/d/1prwMGxgr0cI5yx4lrvMET5x6rD-CQ1y7XuS1PCegE4A/edit# > > Would this be something that we could implement in a new CXF module? And > would anybody on this list be interested in participating in the MP spec > project? > > Thanks in advance! > > Andy > > PS - we have a spec project meeting tomorrow at 10:30am US Eastern time. > Meeting minutes (and a link to the webex) is available here: > > https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit# >
GraphQL Project?
Hi All, I've been involved in an effort to create a MicroProfile GraphQL project that would provide a Java framework for building and deploying GraphQL apps. The API would look similar to JAX-RS (i.e. @Query annotations instead of @GET, etc.). We have a draft project proposal available here: https://docs.google.com/document/d/1prwMGxgr0cI5yx4lrvMET5x6rD-CQ1y7XuS1PCegE4A/edit# Would this be something that we could implement in a new CXF module? And would anybody on this list be interested in participating in the MP spec project? Thanks in advance! Andy PS - we have a spec project meeting tomorrow at 10:30am US Eastern time. Meeting minutes (and a link to the webex) is available here: https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit#
[GitHub] coheigea commented on issue #489: Update maven-processor-plugin; move version to the parent pom
coheigea commented on issue #489: Update maven-processor-plugin; move version to the parent pom URL: https://github.com/apache/cxf/pull/489#issuecomment-451174158 +1 LGTM 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] coheigea commented on issue #490: cxf-rt-transports-udp: minor code improvements to improve test stability
coheigea commented on issue #490: cxf-rt-transports-udp: minor code improvements to improve test stability URL: https://github.com/apache/cxf/pull/490#issuecomment-451158869 +1 LGTM 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] amarkevich closed pull request #5: CXFXJC-30 Unable to resolve transitive extension dependency
amarkevich closed pull request #5: CXFXJC-30 Unable to resolve transitive
extension dependency
URL: https://github.com/apache/cxf-xjc-utils/pull/5
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/cxf-xjc-plugin/src/main/java/org/apache/cxf/maven_plugin/AbstractXSDToJavaMojo.java
b/cxf-xjc-plugin/src/main/java/org/apache/cxf/maven_plugin/AbstractXSDToJavaMojo.java
index fbe12e34..e05290d7 100644
---
a/cxf-xjc-plugin/src/main/java/org/apache/cxf/maven_plugin/AbstractXSDToJavaMojo.java
+++
b/cxf-xjc-plugin/src/main/java/org/apache/cxf/maven_plugin/AbstractXSDToJavaMojo.java
@@ -29,20 +29,17 @@
import java.net.URLClassLoader;
import java.util.ArrayList;
import java.util.Arrays;
+import java.util.HashSet;
import java.util.List;
+import java.util.Set;
import org.apache.maven.artifact.Artifact;
import org.apache.maven.artifact.DependencyResolutionRequiredException;
-import org.apache.maven.artifact.repository.ArtifactRepository;
-import org.apache.maven.artifact.resolver.ArtifactResolutionRequest;
-import org.apache.maven.artifact.resolver.ArtifactResolutionResult;
-import org.apache.maven.execution.MavenSession;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.Component;
import org.apache.maven.plugins.annotations.Parameter;
import org.apache.maven.project.MavenProject;
-import org.apache.maven.repository.RepositorySystem;
import org.codehaus.plexus.archiver.jar.JarArchiver;
import org.codehaus.plexus.archiver.jar.Manifest;
import org.codehaus.plexus.archiver.jar.Manifest.Attribute;
@@ -50,6 +47,15 @@
import org.codehaus.plexus.util.cli.CommandLineUtils;
import org.codehaus.plexus.util.cli.Commandline;
import org.codehaus.plexus.util.cli.StreamConsumer;
+import org.eclipse.aether.RepositoryException;
+import org.eclipse.aether.RepositorySystem;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.DefaultArtifact;
+import org.eclipse.aether.collection.CollectRequest;
+import org.eclipse.aether.graph.Dependency;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.resolution.ArtifactResult;
+import org.eclipse.aether.resolution.DependencyRequest;
import org.sonatype.plexus.build.incremental.BuildContext;
/**
@@ -78,13 +84,22 @@
@Component
private BuildContext buildContext;
-
+
@Component
private RepositorySystem repository;
-
-@Component
-private MavenSession session;
-
+
+/**
+ * The current repository/network configuration of Maven.
+ */
+@Parameter(defaultValue = "${repositorySystemSession}", readonly = true)
+private RepositorySystemSession repoSession;
+
+/**
+ * The project's remote repositories to use for the resolution of plugins
and their dependencies.
+ */
+@Parameter(defaultValue = "${project.remotePluginRepositories}", readonly
= true)
+private List remoteRepos;
+
/**
* Allows running in a separate process.
*/
@@ -115,7 +130,7 @@
*/
@Parameter(property = "plugin.artifacts", readonly = true, required = true)
private List pluginArtifacts;
-
+
abstract String getOutputDir();
@@ -311,42 +326,24 @@ public boolean accept(File dir, String name) {
}
return xsdFiles;
}
-
-private List resolve(String artifactDescriptor) throws
MojoExecutionException {
-String[] s = artifactDescriptor.split(":");
-
-String type = s.length >= 4 ? s[3] : "jar";
-Artifact artifact = repository.createArtifact(s[0], s[1], s[2], type);
-ArtifactResolutionRequest request = new ArtifactResolutionRequest();
-request.setArtifact(artifact);
-
-request.setResolveRoot(true).setResolveTransitively(true);
-request.setServers(session.getRequest().getServers());
-request.setMirrors(session.getRequest().getMirrors());
-request.setProxies(session.getRequest().getProxies());
-request.setLocalRepository(session.getLocalRepository());
-List r = new ArrayList();
-r.addAll(project.getPluginArtifactRepositories());
-r.addAll(project.getRemoteArtifactRepositories());
-r.addAll(session.getRequest().getRemoteRepositories());
-r.addAll(session.getRequest().getPluginArtifactRepositories());
-request.setRemoteRepositories(r);
-ArtifactResolutionResult result = repository.resolve(request);
-List files = new ArrayList();
-for (Artifact a : result.getArtifacts()) {
-if (a.getFile() == null) {
-throw new MojoExecutionException("Unable to resolve " +
[GitHub] coheigea commented on issue #5: CXFXJC-30 Unable to resolve transitive extension dependency
coheigea commented on issue #5: CXFXJC-30 Unable to resolve transitive extension dependency URL: https://github.com/apache/cxf-xjc-utils/pull/5#issuecomment-451132792 +1 LGTM 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
