Wildfly Glow - Behind corporate proxy - Connection refused

[ralfbat...@gmail.com]

Dear Wildfly-Team, I am trying to use the new wildfly-maven-plugin with auto discovering. It seems the plugin wants to connect to a remote server. 

I get this error:

Exception occured while retrieving known Galleon feature-packs for version 34.0.1.Final. Cause: Connection refused: connect 

As starting point, I tried to build one of the quickstart examples for version 34.0.1.Final. (microprofile-reactive-messaging-kafka)

I couldn't find any information in here: https://docs.wildfly.org/wildfly-glow/#_automatic_identification_of_wildfly_galleon_layers

Also running with mvn -X didn't show which remote server has to be available.

What can I do for making this running?

Best Regards,

Ralf

[Jean Francois Denise]

Hi,

you are right, Glow retrieves information from this server: https://github.com/wildfly/wildfly-galleon-feature-packs

It needs to be accessible.

JF

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/3bca29bb-c82c-4eb5-84b8-b9b2b2971756n%40googlegroups.com.

[Torsten Liermann]

Translation into English:

Do you see the possibility that we can make the sources configurable and implement them in such a way that, in restrictive networks or CI/CD pipelines, nothing is loaded from the internet but exclusively through an internal repository manager?

[Jean Francois Denise]

It seems that we should package this metadata in a way that makes it discoverable in maven. That is not the case today.

We have an offline mode designed for the WildFly Glow CLI. It "would" work in a Maven context but is not great. 

With internet access, you use the wildfly-glow CLI and call: wildfly-glow go-offline [--server-version=<a version] [--cloud]

Enable cloud if you want to build a server for the cloud. use server-version if you don't want to use the latest.

WildFly Glow generates a glow-offline.zip. The file must be put in the JVM working directory to be retrieved. That could be an issue in your maven context.

Let me know if that would work for you?

To view this discussion visit https://groups.google.com/d/msgid/wildfly/73d232f2-3cae-46b5-902c-af083a5cc37dn%40googlegroups.com.

[ralfbat...@gmail.com]

Thank you for your reply. I truly believe that if the auto discovering mode should be used, it should fetch the dependencies via maven repositories. No company likes to open the firewall settings, it will be very hard to convince the security departement to accept this.

For my understanding, what is the difference by specifying the layers manually compared to the auto discovery mode? It would be very dangerous if details of the application is sent to this remote server.

Regards, Ralf

[Jean Francois Denise]

Thank-you for your feedback, I am looking at deploying/resolving the metadata in maven. I will keep you posted in this thread.

For your question, the difference is that WIldFly Glow scans the binary locally and produces the set of Galleon layers and feature-packs required. No detail of the application is sent to the server.

JF

To view this discussion visit https://groups.google.com/d/msgid/wildfly/4f40e16b-3531-44d8-a67c-e6e0b5930fdcn%40googlegroups.com.

[Jean Francois Denise]

Hi,

WildFly Glow 1.3.0 has just been released, it is now retrieving the required metadata from maven. This new WildFly Glow release has been upgraded in the WildFly Maven Plugin main branch. As soon as a new WildFly Maven Plugin 5.x release is available, you should upgrade to this release, that will solve your issue.

Thank-you again for your feedback.

JF