[JBoss JIRA] (WFLY-3740) standalone.sh does not compute correct module path in Cygwin
by David Del Vecchio (JIRA)
David Del Vecchio created WFLY-3740:
---------------------------------------
Summary: standalone.sh does not compute correct module path in Cygwin
Key: WFLY-3740
URL: https://issues.jboss.org/browse/WFLY-3740
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.1.0.Final
Environment: Windows with Cygwin
Reporter: David Del Vecchio
Assignee: Jason Greene
Priority: Minor
standalone.sh does not seem to compute the correct JBOSS_MODULEPATH on Cygwin as a result, starting up the server gives the following error:
{{org.jboss.modules.ModuleNotFoundException: org.jboss.as.standalone:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240)
at org.jboss.modules.Main.main(Main.java:385)}}
The problem seems to be somewhat related to this issue in that a mix of Windows and Unix style paths are being computed:
https://issues.jboss.org/browse/WFLY-2523
Since {{JBOSS_MODULEPATH}} is not set until after all the paths (such as {{JBOSS_HOME}}) have been converted to Windows style, {{JBOSS_MODULEPATH}} ends up with a Unix style forward slash at the end of what is otherwise a Windows style path.
The fix for me was to move the code which sets the {{JBOSS_MODULEPATH}} to earlier in the script. I moved it to right after the export JBOSS_HOME line:
{{...
export JBOSS_HOME
if [ "x$JBOSS_MODULEPATH" = "x" ]; then
JBOSS_MODULEPATH="$JBOSS_HOME/modules"
fi
...}}
Probably the key thing is just that the {{JBOSS_MODULEPATH}} gets set before everything is switched to Windows paths in this section of the script:
{{# For Cygwin, switch paths to Windows format before running java
if $cygwin; then
JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"`
JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"`
JBOSS_MODULEPATH=`cygpath --path --windows "$JBOSS_MODULEPATH"`
JBOSS_BASE_DIR=`cygpath --path --windows "$JBOSS_BASE_DIR"`
JBOSS_LOG_DIR=`cygpath --path --windows "$JBOSS_LOG_DIR"`
JBOSS_CONFIG_DIR=`cygpath --path --windows "$JBOSS_CONFIG_DIR"`
fi}}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3740) standalone.sh does not compute correct module path in Cygwin
by David Del Vecchio (JIRA)
[ https://issues.jboss.org/browse/WFLY-3740?page=com.atlassian.jira.plugin.... ]
David Del Vecchio updated WFLY-3740:
------------------------------------
Description:
standalone.sh does not seem to compute the correct JBOSS_MODULEPATH on Cygwin as a result, starting up the server gives the following error:
{{org.jboss.modules.ModuleNotFoundException: org.jboss.as.standalone:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240)
at org.jboss.modules.Main.main(Main.java:385)}}
The problem seems to be somewhat related to this issue in that a mix of Windows and Unix style paths are being computed:
https://issues.jboss.org/browse/WFLY-2523
Since {{JBOSS_MODULEPATH}} is not set until after all the paths (such as {{JBOSS_HOME}}) have been converted to Windows style, {{JBOSS_MODULEPATH}} ends up with a Unix style forward slash at the end of what is otherwise a Windows style path.
The fix for me was to move the code which sets the {{JBOSS_MODULEPATH}} to earlier in the script. I moved it to right after the {{export JBOSS_HOME}} line: {{
...
export JBOSS_HOME
if [ "x$JBOSS_MODULEPATH" = "x" ]; then
JBOSS_MODULEPATH="$JBOSS_HOME/modules"
fi
...}}
Probably the key thing is just that the {{JBOSS_MODULEPATH}} gets set before everything is switched to Windows paths in this section of the script:
{{# For Cygwin, switch paths to Windows format before running java
if $cygwin; then
JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"`
JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"`
JBOSS_MODULEPATH=`cygpath --path --windows "$JBOSS_MODULEPATH"`
JBOSS_BASE_DIR=`cygpath --path --windows "$JBOSS_BASE_DIR"`
JBOSS_LOG_DIR=`cygpath --path --windows "$JBOSS_LOG_DIR"`
JBOSS_CONFIG_DIR=`cygpath --path --windows "$JBOSS_CONFIG_DIR"`
fi}}
was:
standalone.sh does not seem to compute the correct JBOSS_MODULEPATH on Cygwin as a result, starting up the server gives the following error:
{{org.jboss.modules.ModuleNotFoundException: org.jboss.as.standalone:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240)
at org.jboss.modules.Main.main(Main.java:385)}}
The problem seems to be somewhat related to this issue in that a mix of Windows and Unix style paths are being computed:
https://issues.jboss.org/browse/WFLY-2523
Since {{JBOSS_MODULEPATH}} is not set until after all the paths (such as {{JBOSS_HOME}}) have been converted to Windows style, {{JBOSS_MODULEPATH}} ends up with a Unix style forward slash at the end of what is otherwise a Windows style path.
The fix for me was to move the code which sets the {{JBOSS_MODULEPATH}} to earlier in the script. I moved it to right after the export JBOSS_HOME line:
{{...
export JBOSS_HOME
if [ "x$JBOSS_MODULEPATH" = "x" ]; then
JBOSS_MODULEPATH="$JBOSS_HOME/modules"
fi
...}}
Probably the key thing is just that the {{JBOSS_MODULEPATH}} gets set before everything is switched to Windows paths in this section of the script:
{{# For Cygwin, switch paths to Windows format before running java
if $cygwin; then
JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"`
JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"`
JBOSS_MODULEPATH=`cygpath --path --windows "$JBOSS_MODULEPATH"`
JBOSS_BASE_DIR=`cygpath --path --windows "$JBOSS_BASE_DIR"`
JBOSS_LOG_DIR=`cygpath --path --windows "$JBOSS_LOG_DIR"`
JBOSS_CONFIG_DIR=`cygpath --path --windows "$JBOSS_CONFIG_DIR"`
fi}}
> standalone.sh does not compute correct module path in Cygwin
> ------------------------------------------------------------
>
> Key: WFLY-3740
> URL: https://issues.jboss.org/browse/WFLY-3740
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.Final
> Environment: Windows with Cygwin
> Reporter: David Del Vecchio
> Assignee: Jason Greene
> Priority: Minor
>
> standalone.sh does not seem to compute the correct JBOSS_MODULEPATH on Cygwin as a result, starting up the server gives the following error:
> {{org.jboss.modules.ModuleNotFoundException: org.jboss.as.standalone:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240)
> at org.jboss.modules.Main.main(Main.java:385)}}
> The problem seems to be somewhat related to this issue in that a mix of Windows and Unix style paths are being computed:
> https://issues.jboss.org/browse/WFLY-2523
> Since {{JBOSS_MODULEPATH}} is not set until after all the paths (such as {{JBOSS_HOME}}) have been converted to Windows style, {{JBOSS_MODULEPATH}} ends up with a Unix style forward slash at the end of what is otherwise a Windows style path.
> The fix for me was to move the code which sets the {{JBOSS_MODULEPATH}} to earlier in the script. I moved it to right after the {{export JBOSS_HOME}} line: {{
> ...
> export JBOSS_HOME
> if [ "x$JBOSS_MODULEPATH" = "x" ]; then
> JBOSS_MODULEPATH="$JBOSS_HOME/modules"
> fi
> ...}}
> Probably the key thing is just that the {{JBOSS_MODULEPATH}} gets set before everything is switched to Windows paths in this section of the script:
> {{# For Cygwin, switch paths to Windows format before running java
> if $cygwin; then
> JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"`
> JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"`
> JBOSS_MODULEPATH=`cygpath --path --windows "$JBOSS_MODULEPATH"`
> JBOSS_BASE_DIR=`cygpath --path --windows "$JBOSS_BASE_DIR"`
> JBOSS_LOG_DIR=`cygpath --path --windows "$JBOSS_LOG_DIR"`
> JBOSS_CONFIG_DIR=`cygpath --path --windows "$JBOSS_CONFIG_DIR"`
> fi}}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect when recursive=true
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-3705:
--------------------------------------
Pull https://github.com/wildfly/wildfly/pull/6591 now passes the entire suite test.
> read-resource recursive-depth has no effect when recursive=true
> ---------------------------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation, Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
> The above snippet works as follows: recurs IF recursive is set AND (either recursive-depth is not defined OR recursive-depth is greater than 0).
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3739) Change Arquillian containers to launch the process using the launcher API in core
by James Perkins (JIRA)
James Perkins created WFLY-3739:
-----------------------------------
Summary: Change Arquillian containers to launch the process using the launcher API in core
Key: WFLY-3739
URL: https://issues.jboss.org/browse/WFLY-3739
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Test Suite
Reporter: James Perkins
Assignee: James Perkins
WildFly Core now includes a launcher API to generate the commands and optionally launch a WildFly process. Arquillian should be changed to use this API rather than relying on creating the commands and the process on it's own.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf commented on WFLY-3189:
--------------------------------------
One additional validation problem:
I pulled "jboss-ejb3-2_0.xsd" and "jboss-ejb3-spec-2_0.xsd" in an Eclipse project. Here, there was only one validation error:
cos-nonambig: "http://java.sun.com/xml/ns/javaee":assembly-descriptor and "http://java.sun.com/xml/ns/javaee":assembly-descriptor (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
In file "jboss-ejb3-spec-2_0.xsd", line 126
This is this line:
<xs:complexType name="jboss-ejb-jarType">
<xs:complexContent>
<xs:extension base="javaee:ejb-jarType">
<xs:sequence>
<xs:element ref="jboss:enterprise-beans" minOccurs="0"/>
<xs:element name="assembly-descriptor" type="javaee:assembly-descriptorType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="impl-version" type="javaee:dewey-versionType" fixed="2.0" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
I think the problem is the "assembly-descriptor" definition: this one is already defined in the base type "javaee:ejb-jarType", and thus it results in an error. If I remove this line, at least those two files validate.
But after creating "jboss-ejb3.xml" file, I observe the same "Cannot resolve the name..." errors.
> Error validating jboss-ejb3.xml.
> --------------------------------
>
> Key: WFLY-3189
> URL: https://issues.jboss.org/browse/WFLY-3189
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final
> Reporter: shinzey shinzey
> Assignee: David Lloyd
>
> I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
> {noformat}
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
> src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
> {noformat}
> The jboss-ejb3.xml is quite simple:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss:ejb-jar version="3.1" impl-version="2.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:s="urn:security:1.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
> http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
> <assembly-descriptor>
> <s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>testsd</s:security-domain>
> </s:security>
> </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3738) Secured JavaEE appclient hangs on invalid login
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-3738?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf updated WFLY-3738:
---------------------------------
Attachment: standalone.xml
That's my config file with all changes necessary to reproduce this sample (+logging of the security layer)
> Secured JavaEE appclient hangs on invalid login
> -----------------------------------------------
>
> Key: WFLY-3738
> URL: https://issues.jboss.org/browse/WFLY-3738
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Application Client
> Affects Versions: 8.1.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: Security.ear, standalone.xml
>
>
> See attached sample EAR file: it contains a secured EJB and a JavaEE application client. When running the JavaEE application client, you are prompted to enter a user/password, which causes an authentication against a security domain (the prompt to enter login/password does not work correctly, so enter username when nothing more happens, press enter, enter password when nothing more happens and press enter ;-)).
> If you enter valid credentials (e.g. "admin/admin" or "kunde/kunde"), everything is fine. But if you enter e.g. an invalid password, the app client container does not exit. It hangs at the step
> "20:39:28,649 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: WildFly 8.1.0.Final "Kenny" stopped in 339ms"
> To reproduce:
> a) modify "standalone.xml":
> a.1) I need a custom realm:
> <security-realm name="KnaufRealm">
> <authentication>
> <jaas name="knaufsecurity"/>
> </authentication>
> </security-realm>
> a.2) add this security domain:
> <security-domain name="knaufsecurity" cache-type="default">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT PASSWORT FROM BENUTZER WHERE LOGIN=?"/>
> <module-option name="rolesQuery" value="SELECT R.ROLLE, 'Roles' FROM ROLLE AS R, BENUTZER_ROLLE AS BR, BENUTZER AS B WHERE B.LOGIN=? AND BR.ROLLEN_ID = R.ID AND BR.BENUTZER_ID = B.ID"/>
> <module-option name="unauthenticatedIdentity" value="gast"/>
> </login-module>
> </authentication>
> </security-domain>
> a.3) point the remoting connector to my own security realm:
> <subsystem xmlns="urn:jboss:domain:remoting:2.0">
> <endpoint worker="default"/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="KnaufRealm"/>
> </subsystem>
> b) deploy attached EAR file to the server
> c) run JavaEE application client: %WILDFLY_HOME%\bin\appclient.bat c:\path_to\Security.ear#SecurityClient.jar
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3738) Secured JavaEE appclient hangs on invalid login
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-3738?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf updated WFLY-3738:
---------------------------------
Attachment: Security.ear
> Secured JavaEE appclient hangs on invalid login
> -----------------------------------------------
>
> Key: WFLY-3738
> URL: https://issues.jboss.org/browse/WFLY-3738
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Application Client
> Affects Versions: 8.1.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Stuart Douglas
> Priority: Minor
> Attachments: Security.ear, standalone.xml
>
>
> See attached sample EAR file: it contains a secured EJB and a JavaEE application client. When running the JavaEE application client, you are prompted to enter a user/password, which causes an authentication against a security domain (the prompt to enter login/password does not work correctly, so enter username when nothing more happens, press enter, enter password when nothing more happens and press enter ;-)).
> If you enter valid credentials (e.g. "admin/admin" or "kunde/kunde"), everything is fine. But if you enter e.g. an invalid password, the app client container does not exit. It hangs at the step
> "20:39:28,649 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: WildFly 8.1.0.Final "Kenny" stopped in 339ms"
> To reproduce:
> a) modify "standalone.xml":
> a.1) I need a custom realm:
> <security-realm name="KnaufRealm">
> <authentication>
> <jaas name="knaufsecurity"/>
> </authentication>
> </security-realm>
> a.2) add this security domain:
> <security-domain name="knaufsecurity" cache-type="default">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT PASSWORT FROM BENUTZER WHERE LOGIN=?"/>
> <module-option name="rolesQuery" value="SELECT R.ROLLE, 'Roles' FROM ROLLE AS R, BENUTZER_ROLLE AS BR, BENUTZER AS B WHERE B.LOGIN=? AND BR.ROLLEN_ID = R.ID AND BR.BENUTZER_ID = B.ID"/>
> <module-option name="unauthenticatedIdentity" value="gast"/>
> </login-module>
> </authentication>
> </security-domain>
> a.3) point the remoting connector to my own security realm:
> <subsystem xmlns="urn:jboss:domain:remoting:2.0">
> <endpoint worker="default"/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="KnaufRealm"/>
> </subsystem>
> b) deploy attached EAR file to the server
> c) run JavaEE application client: %WILDFLY_HOME%\bin\appclient.bat c:\path_to\Security.ear#SecurityClient.jar
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3738) Secured JavaEE appclient hangs on invalid login
by Wolfgang Knauf (JIRA)
Wolfgang Knauf created WFLY-3738:
------------------------------------
Summary: Secured JavaEE appclient hangs on invalid login
Key: WFLY-3738
URL: https://issues.jboss.org/browse/WFLY-3738
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Application Client
Affects Versions: 8.1.0.Final
Reporter: Wolfgang Knauf
Assignee: Stuart Douglas
Priority: Minor
See attached sample EAR file: it contains a secured EJB and a JavaEE application client. When running the JavaEE application client, you are prompted to enter a user/password, which causes an authentication against a security domain (the prompt to enter login/password does not work correctly, so enter username when nothing more happens, press enter, enter password when nothing more happens and press enter ;-)).
If you enter valid credentials (e.g. "admin/admin" or "kunde/kunde"), everything is fine. But if you enter e.g. an invalid password, the app client container does not exit. It hangs at the step
"20:39:28,649 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: WildFly 8.1.0.Final "Kenny" stopped in 339ms"
To reproduce:
a) modify "standalone.xml":
a.1) I need a custom realm:
<security-realm name="KnaufRealm">
<authentication>
<jaas name="knaufsecurity"/>
</authentication>
</security-realm>
a.2) add this security domain:
<security-domain name="knaufsecurity" cache-type="default">
<authentication>
<login-module code="Database" flag="required">
<module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
<module-option name="principalsQuery" value="SELECT PASSWORT FROM BENUTZER WHERE LOGIN=?"/>
<module-option name="rolesQuery" value="SELECT R.ROLLE, 'Roles' FROM ROLLE AS R, BENUTZER_ROLLE AS BR, BENUTZER AS B WHERE B.LOGIN=? AND BR.ROLLEN_ID = R.ID AND BR.BENUTZER_ID = B.ID"/>
<module-option name="unauthenticatedIdentity" value="gast"/>
</login-module>
</authentication>
</security-domain>
a.3) point the remoting connector to my own security realm:
<subsystem xmlns="urn:jboss:domain:remoting:2.0">
<endpoint worker="default"/>
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="KnaufRealm"/>
</subsystem>
b) deploy attached EAR file to the server
c) run JavaEE application client: %WILDFLY_HOME%\bin\appclient.bat c:\path_to\Security.ear#SecurityClient.jar
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months