[JBoss JIRA] (WFLY-9971) wsprovide && wsconsume scritps don't work on Windows
by Marek Kopecký (JIRA)
Marek Kopecký created WFLY-9971:
-----------------------------------
Summary: wsprovide && wsconsume scritps don't work on Windows
Key: WFLY-9971
URL: https://issues.jboss.org/browse/WFLY-9971
Project: WildFly
Issue Type: Bug
Components: Scripts, Web Services
Affects Versions: 12.0.0.Final
Reporter: Marek Kopecký
Assignee: R Searls
Priority: Blocker
*Description of the issue:*
Wsprovide and wsconsume scripts don't work on Windows. Scripts print jboss-modules help message with any attributes.
*How reproducible:*
Always
*Steps to Reproduce:*
# wsprovide.bat -h
# wsconsume.bat -h
*Actual results:*
{noformat}
C:\Users\Administrator\playground\wfly.12\wildfly\bin>wsprovide.bat -h
Argument expected for option
Usage: java [-jvmoptions...] -jar jboss-modules.jar [-options...] <module-spec> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -jar <jar-name> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -cp <class-path> <class-name> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -class <class-name> [args...]
java [-jvmoptions...] -jar jboss-modules.jar -addindex [-modify] <jar-name>
where <module-spec> is a valid module specification string
and options include:
-help Display this message
-mp, -modulepath <search path of directories>
A list of directories, separated by ';', where modules may be located
If not specified, the value of the "module.path" system property is used
-class Specify that the final argument is a
class to load from the class path; not compatible with -jar
-cp,-classpath <search path of archives or directories>
A search path for class files; implies -class
-dep,-dependencies <module-spec>[,<module-spec>,...]
A list of module dependencies to add to the class path;
requires -class or -cp
-deptree Print the dependency tree of the given module instead of running it
-debuglog Enable debug mode output to System.out during bootstrap before any logging manager is installed
-jar Specify that the final argument is the name of a
JAR file to run as a module; not compatible with -class
-jaxpmodule <module-spec>
The default JAXP implementation to use of the JDK
-secmgr Run with a security manager installed; not compatible with -secmgrmodule
-secmgrmodule <module-spec>
Run with a security manager module; not compatible with -secmgr
-addindex Specify that the final argument is a
jar to create an index for
-modify Modify the indexes jar in-place
-version Print version and exit
C:\Users\Administrator\playground\wfly.12\wildfly\bin>wsconsume.bat -h
Argument expected for option
Usage: java [-jvmoptions...] -jar jboss-modules.jar [-options...] <module-spec> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -jar <jar-name> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -cp <class-path> <class-name> [args...]
java [-jvmoptions...] -jar jboss-modules.jar [-options...] -class <class-name> [args...]
java [-jvmoptions...] -jar jboss-modules.jar -addindex [-modify] <jar-name>
where <module-spec> is a valid module specification string
and options include:
-help Display this message
-mp, -modulepath <search path of directories>
A list of directories, separated by ';', where modules may be located
If not specified, the value of the "module.path" system property is used
-class Specify that the final argument is a
class to load from the class path; not compatible with -jar
-cp,-classpath <search path of archives or directories>
A search path for class files; implies -class
-dep,-dependencies <module-spec>[,<module-spec>,...]
A list of module dependencies to add to the class path;
requires -class or -cp
-deptree Print the dependency tree of the given module instead of running it
-debuglog Enable debug mode output to System.out during bootstrap before any logging manager is installed
-jar Specify that the final argument is the name of a
JAR file to run as a module; not compatible with -class
-jaxpmodule <module-spec>
The default JAXP implementation to use of the JDK
-secmgr Run with a security manager installed; not compatible with -secmgrmodule
-secmgrmodule <module-spec>
Run with a security manager module; not compatible with -secmgr
-addindex Specify that the final argument is a
jar to create an index for
-modify Modify the indexes jar in-place
-version Print version and exit
C:\Users\Administrator\playground\wfly.12\wildfly\bin>
{noformat}
*Expected results:*
{noformat}
C:\Users\Administrator\playground\7.1.0.CR4\jboss-eap-7.1\bin>wsprovide.bat -h
WSProvideTask generates portable JAX-WS artifacts for an endpoint implementation.
usage: wsprovide.bat [options] <endpoint class name>
options:
-h, --help Show this help message
-k, --keep Keep/Generate Java source
-w, --wsdl Enable WSDL file generation
-a, --address=<address> The generated port soap:address in wsdl
-c, --classpath=<path> The classpath that contains the endpoint
-o, --output=<directory> The directory to put generated artifacts
-r, --resource=<directory> The directory to put resource artifacts
-s, --source=<directory> The directory to put Java source
-e, --extension Enable SOAP 1.2 binding extension
-q, --quiet Be somewhat more quiet
-t, --show-traces Show full exception stack traces
-v, --verbose Show full exception stack traces
-l, --load-provider Load the provider and exit (debug utility)
C:\Users\Administrator\playground\7.1.0.CR4\jboss-eap-7.1\bin>wsconsume.bat -h
WSConsumeTask is a cmd line tool that generates portable JAX-WS artifacts from a WSDL file.
usage: wsconsume.bat [options] <wsdl-url>
options:
-h, --help Show this help message
-b, --binding=<file> One or more JAX-WS or JAXB binding files
-k, --keep Keep/Generate Java source
-c --catalog=<file> Oasis XML Catalog file for entity resolution
-j --clientjar=<name> Create a jar file of the generated artifacts for calling the webservice
-p --package=<name> The target package for generated source
-w --wsdlLocation=<loc> Value to use for @WebService.wsdlLocation
-o, --output=<directory> The directory to put generated artifacts
-s, --source=<directory> The directory to put Java source
-t, --target=<2.1|2.2> The JAX-WS specification target
-q, --quiet Be somewhat more quiet
-v, --verbose Show full exception stack traces
-l, --load-consumer Load the consumer and exit (debug utility)
-e, --extension Enable SOAP 1.2 binding extension
-a, --additionalHeaders Enable processing of implicit SOAP headers
-d --encoding=<charset> The charset encoding to use for generated sources
-n, --nocompile Do not compile generated sources
C:\Users\Administrator\playground\7.1.0.CR4\jboss-eap-7.1\bin>
{noformat}
*Additional info:*
cc: [~asoldano], [~jbliznak]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9970) WildFly 12.0.0.Final + Java 9 ignores @WebServlet
by Анатолий Широков (JIRA)
[ https://issues.jboss.org/browse/WFLY-9970?page=com.atlassian.jira.plugin.... ]
Анатолий Широков updated WFLY-9970:
-----------------------------------
Summary: WildFly 12.0.0.Final + Java 9 ignores @WebServlet (was: WildFly 12.0.0.Final + Java 9 ignore @WebServlet)
> WildFly 12.0.0.Final + Java 9 ignores @WebServlet
> -------------------------------------------------
>
> Key: WFLY-9970
> URL: https://issues.jboss.org/browse/WFLY-9970
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 12.0.0.Final
> Environment: os: Windows Proffessional 7 64 bit
> jdk: Oracle JDK 9.0.4, Oracle JDK 1.8.0_162
> mvn: Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T10:58:13+03:00)
> Reporter: Анатолий Широков
>
> I have WildFly 12.0.0.Final server running on JDK 9. I have simple maven based annotated servlet project: https://github.com/anatoly-spb/simple-annotated-servlet .
> If I build my project with Java 9, WildFly does see @WebServlet annotation. If I build my project with Java 1.8, WildFly uses @WebServlet annotation and works as expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9970) WildFly 12.0.0.Final + Java 9 ignore @WebServlet
by Анатолий Широков (JIRA)
[ https://issues.jboss.org/browse/WFLY-9970?page=com.atlassian.jira.plugin.... ]
Анатолий Широков updated WFLY-9970:
-----------------------------------
Description:
I have WildFly 12.0.0.Final server running on JDK 9. I have simple maven based annotated servlet project: https://github.com/anatoly-spb/simple-annotated-servlet .
If I build my project with Java 9, WildFly does see @WebServlet annotation. If I build my project with Java 1.8, WildFly uses @WebServlet annotation and works as expected.
was:
I have WildFly 12.0.0.Final server running on JDK 9. I have simple maven based annotated servlet project: https://github.com/anatoly-spb/simple-annotated-servlet .
If I build my project with Java 9, WildFly does see @WebServlet annotation:
If I build my project with Java 1.8, WildFly use @WebServlet annotation and works as expected.
> WildFly 12.0.0.Final + Java 9 ignore @WebServlet
> ------------------------------------------------
>
> Key: WFLY-9970
> URL: https://issues.jboss.org/browse/WFLY-9970
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 12.0.0.Final
> Environment: os: Windows Proffessional 7 64 bit
> jdk: Oracle JDK 9.0.4, Oracle JDK 1.8.0_162
> mvn: Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T10:58:13+03:00)
> Reporter: Анатолий Широков
>
> I have WildFly 12.0.0.Final server running on JDK 9. I have simple maven based annotated servlet project: https://github.com/anatoly-spb/simple-annotated-servlet .
> If I build my project with Java 9, WildFly does see @WebServlet annotation. If I build my project with Java 1.8, WildFly uses @WebServlet annotation and works as expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9970) WildFly 12.0.0.Final + Java 9 ignore @WebServlet
by Анатолий Широков (JIRA)
Анатолий Широков created WFLY-9970:
--------------------------------------
Summary: WildFly 12.0.0.Final + Java 9 ignore @WebServlet
Key: WFLY-9970
URL: https://issues.jboss.org/browse/WFLY-9970
Project: WildFly
Issue Type: Bug
Components: EE
Affects Versions: 12.0.0.Final
Environment: os: Windows Proffessional 7 64 bit
jdk: Oracle JDK 9.0.4, Oracle JDK 1.8.0_162
mvn: Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T10:58:13+03:00)
Reporter: Анатолий Широков
I have WildFly 12.0.0.Final server running on JDK 9. I have simple maven based annotated servlet project: https://github.com/anatoly-spb/simple-annotated-servlet .
If I build my project with Java 9, WildFly does see @WebServlet annotation:
If I build my project with Java 1.8, WildFly use @WebServlet annotation and works as expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9943) Sometimes WF process does not exit on RHEL 6 (32/64 bit) and IBM JDK 8
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-9943?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-9943:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1552040
Bugzilla Update: Perform
> Sometimes WF process does not exit on RHEL 6 (32/64 bit) and IBM JDK 8
> ----------------------------------------------------------------------
>
> Key: WFLY-9943
> URL: https://issues.jboss.org/browse/WFLY-9943
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 12.0.0.Final
> Environment: RHEL 6 32/64 bit
> IBM SDK 8.0.5.10:
> {code}java version "1.8.0_161
> Java(TM) SE Runtime Environment (build 8.0.5.10 - pxi3280sr5fp10-20180214_01(SR5 FP10))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux x86-32 20180208_378436 (JIT enabled, AOT enabled)
> OpenJ9 - 39bb844
> OMR - c04ccb2
> IBM - 2321a81)
> JCL - 20180209_01 based on Oracle jdk8u161-b12
> {code}
> Reporter: Miroslav Novak
> Assignee: Jason Greene
> Attachments: pstack.txt
>
>
> Sometimes happens that WF12 process does not exit when :shutdown CLI operation called and hangs indefinitely. This happens only RHEL 6 (32/64 bit) with IBM SDK8.
> Calling kill -3 does not create any javacore dump and only output could be gathered from pstack (attached). It indicates that JVM shutdown thread is hanging on:
> {code}
> Thread 25 (Thread 0xb7792b70 (LWP 25507)):
> #0 0x00bd4424 in __kernel_vsyscall ()
> #1 0x00b2243c in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2 0x004f8b1f in monitor_wait_original () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9thr29.so
> #3 0x004f9957 in omrthread_monitor_wait () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9thr29.so
> #4 0x0033e217 in protectedDestroyJavaVM () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9vm29.so
> #5 0x0042cf6e in omrsig_protect () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9prt29.so
> #6 0x0033db93 in DestroyJavaVM () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libj9vm29.so
> #7 0x00815999 in DestroyJavaVM () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/lib/i386/default/libjvm.so
> #8 0x00528649 in JavaMain () from /qa/tools/opt/ibm-java-i386-sdk-8.0-5.10/jre/bin/../lib/i386/jli/libjli.so
> #9 0x00b1ebc9 in start_thread () from /lib/libpthread.so.0
> #10 0x001fc04e in clone () from /lib/libc.so.6
> {code}
> There are other 24 threads which might be blocking this thread or a dead lock. This appears to be problem in IBM SDK 8 in combination RHEL 6 GLIBC_2.3.2 library.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 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], I attached a fixed aesh-readline-1.5.jar, this one is not dependent on the container var env. This should work with tty returning "not a tty", if you could attach the logs that I check the traces?
Thanks for your help.
JF
> 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, 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, 2 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 updated WFCORE-3667:
-----------------------------------------
Attachment: aesh-readline-1.5.jar
> 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, 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, 2 months
[JBoss JIRA] (WFLY-9968) Provides jboss-deployment-structure.xml for all known applications, or a tool to generate it.
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-9968?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise updated WFLY-9968:
---------------------------------------
Component/s: (was: CLI)
(was: Documentation)
> Provides jboss-deployment-structure.xml for all known applications, or a tool to generate it.
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-9968
> URL: https://issues.jboss.org/browse/WFLY-9968
> Project: WildFly
> Issue Type: Feature Request
> 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, 2 months
[JBoss JIRA] (WFLY-9968) Provides jboss-deployment-structure.xml for all known applications, or a tool to generate it.
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-9968?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise reassigned WFLY-9968:
------------------------------------------
Assignee: Jason Greene (was: Jean-Francois Denise)
> Provides jboss-deployment-structure.xml for all known applications, or a tool to generate it.
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-9968
> URL: https://issues.jboss.org/browse/WFLY-9968
> Project: WildFly
> Issue Type: Feature Request
> Affects Versions: 10.0.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: all
> Reporter: Gaétan QUENTIN
> Assignee: Jason Greene
>
> 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, 2 months
[JBoss JIRA] (WFCORE-3671) CLI syntax for "cd" command does not work the same in EAP 7.1
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3671?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise moved JBEAP-14334 to WFCORE-3671:
------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3671 (was: JBEAP-14334)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.1.0.GA)
> CLI syntax for "cd" command does not work the same in EAP 7.1
> -------------------------------------------------------------
>
> Key: WFCORE-3671
> URL: https://issues.jboss.org/browse/WFCORE-3671
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Minor
>
> Start up EAP 6.4 or 7.0 in domain mode and connect with jboss-cli.sh
> I can do these commands:
> [domain@localhost:9990 /] cd host
> [domain@localhost:9990 host] cd master
> [domain@localhost:9990 host=master]
> On EAP 7.1 it gives me an error:
> Failed to validate address: the response from the controller doesn't contain result.
> I can only do "cd host=master" successfully.
> Is this a bug/regression or an intentional change in EAP 7.1?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months