[JBoss JIRA] (WFLY-9969) JDK9 + FIPS BC, unable to configure
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-9969?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-9969:
-------------------------------
Description:
* Configure BouncyCastleFipsProvider in java
{code:title=$\{jdk9_home\}/conf/security/java.security}
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
security.provider.2=SUN
security.provider.3=SunRsaSign
security.provider.4=SunEC
security.provider.5=SunJSSE BCFIPS
security.provider.6=SunJCE
security.provider.7=SunJGSS
security.provider.8=SunSASL
security.provider.9=XMLDSig
security.provider.10=SunPCSC
security.provider.11=JdkLDAP
security.provider.12=JdkSASL
security.provider.13=SunPKCS11
{code}
* configure -cp of java process based on https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC-GU.... It means in ${jboss_home}/bin/standalone.conf put -cp option with bcfips jar
{{JAVA_OPTS="-Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -cp /home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar"}}
* Configure additional logging
{code}
/subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
/subsystem=logging/logger=org.wildfly.extension.elytron:add(level=ALL)
{code}
* Run CLI command
{{/subsystem=elytron/key-store=bcfks_keystore:add(path=keystore.bcfks,relative-to=jboss.server.config.dir, type="BCFKS", credential-reference={clear-text=password})}}
* For some reason BouncyCastleFipsProvider is not listed among providers returned by Security.getProviders() and therefore BCFKS can't be resolved
{code}
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/mchoma/eap/7.2.0.EL12.CR1/jboss-eap-7.2
JAVA: /opt/java/jdk-9.0.1_bcfips/bin/java
JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -cp /home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n
=========================================================================
...
09:20:16,630 TRACE [org.wildfly.extension.elytron] (MSC service thread 1-3) No provider identified for name [null] and algorithm [BCFKS] between [SUN version 9, ApacheXMLDSig version 2.11, SunRsaSign version 9, SunEC version 9, SunJSSE version 9, SunJCE version 9, SunJGSS version 9, SunSASL version 9, XMLDSig version 9, SunPCSC version 9, JdkLDAP version 9, JdkSASL version 9, SunPKCS11 version 9, SunDeploy-MozillaJSS version 1.5, WildFlyElytron version 1.0, TLSP version 1.0, openssl version 1.0]
09:20:16,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.key-store.bcfks_keystore: org.jboss.msc.service.StartException in service org.wildfly.security.key-store.bcfks_keystore: WFLYELY00004: Unable to start the service.
at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:148)
at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00012: No suitable provider found for type 'BCFKS'
at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.resolveProvider(KeyStoreService.java:156)
at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:110)
... 8 more
{code}
With same java I can run succesfully this java code
{code:java|title=TestBCLoaded.java}
import java.security.*;
public class TestBCLoaded {
public static void main(String[] args) {
Provider p = Security.getProvider("org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider");
if (p==null){
System.out.println("Not Loaded: org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider");
}
p = Security.getProvider("BouncyCastleFipsProvider");
if (p==null){
System.out.println("Not Loaded: BouncyCastleFipsProvider");
}
p = Security.getProvider("BCFIPS");
if (p==null){
System.out.println("Not Loaded: BCFIPS");
} else {
System.out.println("Provider name is " + p.getName());
System.out.println("Provider version # is " + p.getVersion());
System.out.println("Provider info is " + p.getInfo());
}
}
}
{code}
{{[mchoma@localhost jdk9Test]$ java -cp .:/home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar TestBCLoaded
Not Loaded: org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
Not Loaded: BouncyCastleFipsProvider
Provider name is BCFIPS
Provider version # is 0.9
Provider info is BouncyCastle Security Provider (FIPS edition) v0.90}}
was:
* Configure BouncyCastleFipsProvider in java
{code:title=${jdk9_home}/conf/security/java.security}
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
security.provider.2=SUN
security.provider.3=SunRsaSign
security.provider.4=SunEC
security.provider.5=SunJSSE BCFIPS
security.provider.6=SunJCE
security.provider.7=SunJGSS
security.provider.8=SunSASL
security.provider.9=XMLDSig
security.provider.10=SunPCSC
security.provider.11=JdkLDAP
security.provider.12=JdkSASL
security.provider.13=SunPKCS11
{code}
* configure -cp of java process based on https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC-GU.... It means in ${jboss_home}/bin/standalone.conf put -cp option with bcfips jar
{{JAVA_OPTS="-Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -cp /home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar"}}
* Configure additional logging
{code}
/subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
/subsystem=logging/logger=org.wildfly.extension.elytron:add(level=ALL)
{code}
* Run CLI command
{{/subsystem=elytron/key-store=bcfks_keystore:add(path=keystore.bcfks,relative-to=jboss.server.config.dir, type="BCFKS", credential-reference={clear-text=password})}}
* For some reason BouncyCastleFipsProvider is not listed among providers returned by Security.getProviders() and therefore BCFKS can't be resolved
{code}
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/mchoma/eap/7.2.0.EL12.CR1/jboss-eap-7.2
JAVA: /opt/java/jdk-9.0.1_bcfips/bin/java
JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -cp /home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n
=========================================================================
...
09:20:16,630 TRACE [org.wildfly.extension.elytron] (MSC service thread 1-3) No provider identified for name [null] and algorithm [BCFKS] between [SUN version 9, ApacheXMLDSig version 2.11, SunRsaSign version 9, SunEC version 9, SunJSSE version 9, SunJCE version 9, SunJGSS version 9, SunSASL version 9, XMLDSig version 9, SunPCSC version 9, JdkLDAP version 9, JdkSASL version 9, SunPKCS11 version 9, SunDeploy-MozillaJSS version 1.5, WildFlyElytron version 1.0, TLSP version 1.0, openssl version 1.0]
09:20:16,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.key-store.bcfks_keystore: org.jboss.msc.service.StartException in service org.wildfly.security.key-store.bcfks_keystore: WFLYELY00004: Unable to start the service.
at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:148)
at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00012: No suitable provider found for type 'BCFKS'
at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.resolveProvider(KeyStoreService.java:156)
at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:110)
... 8 more
{code}
With same java I can run succesfully this java code
{code:java|title=TestBCLoaded.java}
import java.security.*;
public class TestBCLoaded {
public static void main(String[] args) {
Provider p = Security.getProvider("org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider");
if (p==null){
System.out.println("Not Loaded: org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider");
}
p = Security.getProvider("BouncyCastleFipsProvider");
if (p==null){
System.out.println("Not Loaded: BouncyCastleFipsProvider");
}
p = Security.getProvider("BCFIPS");
if (p==null){
System.out.println("Not Loaded: BCFIPS");
} else {
System.out.println("Provider name is " + p.getName());
System.out.println("Provider version # is " + p.getVersion());
System.out.println("Provider info is " + p.getInfo());
}
}
}
{code}
{{[mchoma@localhost jdk9Test]$ java -cp .:/home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar TestBCLoaded
Not Loaded: org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
Not Loaded: BouncyCastleFipsProvider
Provider name is BCFIPS
Provider version # is 0.9
Provider info is BouncyCastle Security Provider (FIPS edition) v0.90}}
> JDK9 + FIPS BC, unable to configure
> -----------------------------------
>
> Key: WFLY-9969
> URL: https://issues.jboss.org/browse/WFLY-9969
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Final
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> * Configure BouncyCastleFipsProvider in java
> {code:title=$\{jdk9_home\}/conf/security/java.security}
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> security.provider.2=SUN
> security.provider.3=SunRsaSign
> security.provider.4=SunEC
> security.provider.5=SunJSSE BCFIPS
> security.provider.6=SunJCE
> security.provider.7=SunJGSS
> security.provider.8=SunSASL
> security.provider.9=XMLDSig
> security.provider.10=SunPCSC
> security.provider.11=JdkLDAP
> security.provider.12=JdkSASL
> security.provider.13=SunPKCS11
> {code}
> * configure -cp of java process based on https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC-GU.... It means in ${jboss_home}/bin/standalone.conf put -cp option with bcfips jar
> {{JAVA_OPTS="-Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -cp /home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar"}}
> * Configure additional logging
> {code}
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> /subsystem=logging/logger=org.wildfly.extension.elytron:add(level=ALL)
> {code}
> * Run CLI command
> {{/subsystem=elytron/key-store=bcfks_keystore:add(path=keystore.bcfks,relative-to=jboss.server.config.dir, type="BCFKS", credential-reference={clear-text=password})}}
> * For some reason BouncyCastleFipsProvider is not listed among providers returned by Security.getProviders() and therefore BCFKS can't be resolved
> {code}
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/mchoma/eap/7.2.0.EL12.CR1/jboss-eap-7.2
> JAVA: /opt/java/jdk-9.0.1_bcfips/bin/java
> JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -cp /home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n
> =========================================================================
> ...
> 09:20:16,630 TRACE [org.wildfly.extension.elytron] (MSC service thread 1-3) No provider identified for name [null] and algorithm [BCFKS] between [SUN version 9, ApacheXMLDSig version 2.11, SunRsaSign version 9, SunEC version 9, SunJSSE version 9, SunJCE version 9, SunJGSS version 9, SunSASL version 9, XMLDSig version 9, SunPCSC version 9, JdkLDAP version 9, JdkSASL version 9, SunPKCS11 version 9, SunDeploy-MozillaJSS version 1.5, WildFlyElytron version 1.0, TLSP version 1.0, openssl version 1.0]
> 09:20:16,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.key-store.bcfks_keystore: org.jboss.msc.service.StartException in service org.wildfly.security.key-store.bcfks_keystore: WFLYELY00004: Unable to start the service.
> at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:148)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00012: No suitable provider found for type 'BCFKS'
> at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.resolveProvider(KeyStoreService.java:156)
> at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:110)
> ... 8 more
> {code}
> With same java I can run succesfully this java code
> {code:java|title=TestBCLoaded.java}
> import java.security.*;
> public class TestBCLoaded {
> public static void main(String[] args) {
> Provider p = Security.getProvider("org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider");
> if (p==null){
> System.out.println("Not Loaded: org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider");
> }
> p = Security.getProvider("BouncyCastleFipsProvider");
> if (p==null){
> System.out.println("Not Loaded: BouncyCastleFipsProvider");
> }
> p = Security.getProvider("BCFIPS");
> if (p==null){
> System.out.println("Not Loaded: BCFIPS");
> } else {
> System.out.println("Provider name is " + p.getName());
> System.out.println("Provider version # is " + p.getVersion());
> System.out.println("Provider info is " + p.getInfo());
> }
> }
> }
> {code}
> {{[mchoma@localhost jdk9Test]$ java -cp .:/home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar TestBCLoaded
> Not Loaded: org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> Not Loaded: BouncyCastleFipsProvider
> Provider name is BCFIPS
> Provider version # is 0.9
> Provider info is BouncyCastle Security Provider (FIPS edition) v0.90}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9968) Provides jboss-deployment-structure.xml for all known applications
by Gaétan QUENTIN (JIRA)
[ https://issues.jboss.org/browse/WFLY-9968?page=com.atlassian.jira.plugin.... ]
Gaétan QUENTIN updated WFLY-9968:
---------------------------------
Description:
It is very painfull to deploy applications since modules system introduction.
The modules conflicts it has introduced is very deifficult to understand , and we cannot afford to waste so many time to deploy war applications , trying to desactivate some modules or some subsystems and see what happens.
Exemple? apache archiva. Since wildfly 10, i desesperatly try to integrate it as war in wildfly.
There is always conflicts: first of one is cxf. But if you exclude it, there are bunch of others problems etc.
So, couldn't it be possible for you to provide the jboss-deployment-structure.xml needed for each well known application, or better, provide a tool which would do it automaticaly?
was:
It is very painpull to deploy applications since modules system introduction.
The modules conflicts it has introduced is very deifficult to understand , and we cannot afford to waste so many time to deploy war applications , trying to desactivate some modules or some subsystems and see what happens.
Exemple? apache archiva. Since wildfly 10, i desesperatly try to integrate it as war in wildfly.
There is always conflicts: first of one is cxf. But if you exclude it, there are bunch of others problems etc.
So, couldn't it be possible for you to provide the jboss-deployment-structure.xml needed for each well known application, or better, provide a tool which would do it automaticaly?
> Provides jboss-deployment-structure.xml for all known applications
> ------------------------------------------------------------------
>
> Key: WFLY-9968
> URL: https://issues.jboss.org/browse/WFLY-9968
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI, Documentation
> Affects Versions: 10.0.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: all
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
>
> It is very painfull to deploy applications since modules system introduction.
> The modules conflicts it has introduced is very deifficult to understand , and we cannot afford to waste so many time to deploy war applications , trying to desactivate some modules or some subsystems and see what happens.
> Exemple? apache archiva. Since wildfly 10, i desesperatly try to integrate it as war in wildfly.
> There is always conflicts: first of one is cxf. But if you exclude it, there are bunch of others problems etc.
> So, couldn't it be possible for you to provide the jboss-deployment-structure.xml needed for each well known application, or better, provide a tool which would do it automaticaly?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9968) Provides jboss-deployment-structure.xml for all known applications
by Gaétan QUENTIN (JIRA)
[ https://issues.jboss.org/browse/WFLY-9968?page=com.atlassian.jira.plugin.... ]
Gaétan QUENTIN updated WFLY-9968:
---------------------------------
Description:
It is very painfull to deploy applications since modules system introduction.
The modules conflicts it has introduced is very difficult to understand , and we cannot afford to waste so many time to deploy war applications , trying to desactivate some modules or some subsystems and see what happens.
Exemple? apache archiva. Since wildfly 10, i desesperatly try to integrate it as war in wildfly.
There is always conflicts: first of one is cxf. But if you exclude it, there are bunch of others problems etc.
So, couldn't it be possible for you to provide the jboss-deployment-structure.xml needed for each well known application, or better, provide a tool which would do it automaticaly?
was:
It is very painfull to deploy applications since modules system introduction.
The modules conflicts it has introduced is very deifficult to understand , and we cannot afford to waste so many time to deploy war applications , trying to desactivate some modules or some subsystems and see what happens.
Exemple? apache archiva. Since wildfly 10, i desesperatly try to integrate it as war in wildfly.
There is always conflicts: first of one is cxf. But if you exclude it, there are bunch of others problems etc.
So, couldn't it be possible for you to provide the jboss-deployment-structure.xml needed for each well known application, or better, provide a tool which would do it automaticaly?
> Provides jboss-deployment-structure.xml for all known applications
> ------------------------------------------------------------------
>
> Key: WFLY-9968
> URL: https://issues.jboss.org/browse/WFLY-9968
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI, Documentation
> Affects Versions: 10.0.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: all
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
>
> It is very painfull to deploy applications since modules system introduction.
> The modules conflicts it has introduced is very difficult to understand , and we cannot afford to waste so many time to deploy war applications , trying to desactivate some modules or some subsystems and see what happens.
> Exemple? apache archiva. Since wildfly 10, i desesperatly try to integrate it as war in wildfly.
> There is always conflicts: first of one is cxf. But if you exclude it, there are bunch of others problems etc.
> So, couldn't it be possible for you to provide the jboss-deployment-structure.xml needed for each well known application, or better, provide a tool which would do it automaticaly?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9968) Provides jboss-deployment-structure.xml for all known applications
by Gaétan QUENTIN (JIRA)
Gaétan QUENTIN created WFLY-9968:
------------------------------------
Summary: Provides jboss-deployment-structure.xml for all known applications
Key: WFLY-9968
URL: https://issues.jboss.org/browse/WFLY-9968
Project: WildFly
Issue Type: Feature Request
Components: CLI, Documentation
Affects Versions: 12.0.0.Final, 11.0.0.Final, 10.0.0.Final
Environment: all
Reporter: Gaétan QUENTIN
Assignee: Jean-Francois Denise
It is very painpull to deploy applications since modules system introduction.
The modules conflicts it has introduced is very deifficult to understand , and we cannot afford to waste so many time to deploy war applications , trying to desactivate some modules or some subsystems and see what happens.
Exemple? apache archiva. Since wildfly 10, i desesperatly try to integrate it as war in wildfly.
There is always conflicts: first of one is cxf. But if you exclude it, there are bunch of others problems etc.
So, couldn't it be possible for you to provide the jboss-deployment-structure.xml needed for each well known application, or better, provide a tool which would do it automaticaly?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3667) Wildfly 12 : jboss-cli.sh in infinite loop
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3667?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3667:
----------------------------------------------
[~gquentin], looking at the attached log it seems that CLI didn't detect that the container is an lxc (that has a buggy tty call behavior).
In my lxc container I can see container=lxc env variable.
Do you have this env variable?
Thanks.
> Wildfly 12 : jboss-cli.sh in infinite loop
> -------------------------------------------
>
> Key: WFCORE-3667
> URL: https://issues.jboss.org/browse/WFCORE-3667
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: ubuntu 16.06 lxd container
> java version "1.8.0_161" oracle
> v12 migrated from v11
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
> Priority: Critical
> Labels: regression
> Attachments: aesh-readline-1.5.jar, jboss-cli-logging.properties, jboss-cli.25300, jboss-cli.log, term.txt
>
>
> i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12:
>
> wildfly@java2:/opt/Wildfly$ ls -la
> drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
> drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
> drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
> drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
> drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
> lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
>
>
> my wildfly management console is on 172.20.12.192.
> v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
>
>
> with wildfly-current link on -> wildfly-11.0.0.Final:
>
> this works perfectly:
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
>
> with wildfly-current -> wildfly-12.0.0.Final:
> this go in infinite loop until crash :
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
> output:
>
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
> ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
> ''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
> ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
> attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3667) Wildfly 12 : jboss-cli.sh in infinite loop
by Gaétan QUENTIN (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3667?page=com.atlassian.jira.plugi... ]
Gaétan QUENTIN commented on WFCORE-3667:
----------------------------------------
after "script /dev/null"
wildfly@java2:~$ tty
/dev/pts/0
wildfly@java2:~$ stty
speed 38400 baud; line = 0;
ixany iutf8
> Wildfly 12 : jboss-cli.sh in infinite loop
> -------------------------------------------
>
> Key: WFCORE-3667
> URL: https://issues.jboss.org/browse/WFCORE-3667
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: ubuntu 16.06 lxd container
> java version "1.8.0_161" oracle
> v12 migrated from v11
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
> Priority: Critical
> Labels: regression
> Attachments: aesh-readline-1.5.jar, jboss-cli-logging.properties, jboss-cli.25300, jboss-cli.log, term.txt
>
>
> i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12:
>
> wildfly@java2:/opt/Wildfly$ ls -la
> drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
> drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
> drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
> drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
> drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
> lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
>
>
> my wildfly management console is on 172.20.12.192.
> v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
>
>
> with wildfly-current link on -> wildfly-11.0.0.Final:
>
> this works perfectly:
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
>
> with wildfly-current -> wildfly-12.0.0.Final:
> this go in infinite loop until crash :
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
> output:
>
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
> ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
> ''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
> ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
> attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3667) Wildfly 12 : jboss-cli.sh in infinite loop
by Gaétan QUENTIN (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3667?page=com.atlassian.jira.plugi... ]
Gaétan QUENTIN commented on WFCORE-3667:
----------------------------------------
[~stalep]
wildfly@java2:~$ tty
not a tty
wildfly@java2:~$ stty
speed 38400 baud; line = 0;
ixany iutf8
root@java2:~# infocmp
# Reconstructed via infocmp from file: /lib/terminfo/x/xterm-256color
xterm-256color|xterm with 256 colors,
am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
colors#256, cols#80, it#8, lines#24, pairs#32767,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE,
kbs=\177, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC,
kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP,
kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P,
kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~,
kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~,
kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~,
kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R,
kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~,
kf31=\E[18;5~, kf32=\E[19;5~, kf33=\E[20;5~,
kf34=\E[21;5~, kf35=\E[23;5~, kf36=\E[24;5~,
kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R, kf4=\EOS,
kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~,
kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~,
kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~,
kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R,
kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
memu=\Em, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM,
rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[27m,
rmul=\E[24m, rs1=\Ec, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
> Wildfly 12 : jboss-cli.sh in infinite loop
> -------------------------------------------
>
> Key: WFCORE-3667
> URL: https://issues.jboss.org/browse/WFCORE-3667
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: ubuntu 16.06 lxd container
> java version "1.8.0_161" oracle
> v12 migrated from v11
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
> Priority: Critical
> Labels: regression
> Attachments: aesh-readline-1.5.jar, jboss-cli-logging.properties, jboss-cli.25300, jboss-cli.log, term.txt
>
>
> i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12:
>
> wildfly@java2:/opt/Wildfly$ ls -la
> drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
> drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
> drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
> drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
> drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
> lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
>
>
> my wildfly management console is on 172.20.12.192.
> v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
>
>
> with wildfly-current link on -> wildfly-11.0.0.Final:
>
> this works perfectly:
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
>
> with wildfly-current -> wildfly-12.0.0.Final:
> this go in infinite loop until crash :
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
> output:
>
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
> ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
> ''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
> ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
> attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9962) ReverseProxyTestCase fails when running after ForwardedHandlerTestCase
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-9962?page=com.atlassian.jira.plugin.... ]
Jan Stourac commented on WFLY-9962:
-----------------------------------
Thanks [~honza889] for spotting this! I am gonna look at this and return back with more info.
> ReverseProxyTestCase fails when running after ForwardedHandlerTestCase
> ----------------------------------------------------------------------
>
> Key: WFLY-9962
> URL: https://issues.jboss.org/browse/WFLY-9962
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Jan Kalina
>
> When ForwardedHandlerTestCase installs {{/subsystem=undertow/configuration=filter/expression-filter=ff}}, even through it removes it after, {{/proxy}} location defined as part of ReverseProxyTestCase setup returns error 404:
> {code}
> testReverseProxy(org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase) Time elapsed: 0.087 sec <<< FAILURE!
> java.lang.AssertionError: expected:<200> but was:<404>
> {code}
> * Direct calling of {{/server1/name}} and {{/server2/name}} from the same tests gives 200 correctly.
> * When I comment out the ff filter setup (or skip whole ForwardedHandlerTestCase), ReverseProxyTestCase suceed.
> * When I copy configuration and deployments from running test and run in standalone server outside of test, proxy works correctly.
> As it is unrelated to my original issue in the end, keeping unassigned.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months