[JBoss JIRA] (WFCORE-2223) Setting JBOSS_MODULEPATH is lost for second start of embed-server
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2223?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-2223:
----------------------------------------------
[~jcacek], Modules are not involved in your case. When you set JBOSS_MODULEPATH, the CLI will use this property value as module path but EmbeddedServer doesn't.
There seems to be a bug in org.boss.as.server.ServerEnvironment. The first time the embedded server is started, line 406 to 412, the modules directory is computed based on the home dir (that doesn't contain any modules because you removed them). The value points to an non existing directory. This value doesn't seem used BUT is set as the value of jboss.modules.dir property. That will cause a problem when the second embed-server is started.
I am wandering if a check shouldn't be added there to fail in such configuration.
When the second embed-server is started, org.boss.as.server.ServerEnvironment line 406/412, a property is found this time for jboss.modules.dir and the value it contains is a non existent modules directory. This does create the exception you are seeing.
I will assign to [~bstansberry2] but I feel that what you are trying to achieve is not supported. The system property to set should be JBOSS_HOME as it is documented in embed-server command help.
> Setting JBOSS_MODULEPATH is lost for second start of embed-server
> -----------------------------------------------------------------
>
> Key: WFCORE-2223
> URL: https://issues.jboss.org/browse/WFCORE-2223
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules
> Reporter: Josef Cacek
> Assignee: David Lloyd
> Priority: Critical
>
> When {{embed-server}} command is used more times in the CLI and a custom {{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct module path.
> The subsequent `embed-server` call results in error:
> {code}
> Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYSRV0118: Determined modules directory does not exist: /tmp/jboss-eap-7.0-no-modules/modules
> {code}
> Using the {{JBOSS_MODULEPATH}} environment variable is documented in https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ELY-895) AuthenticationConfiguration equals() and hashCode()
by David Lloyd (JIRA)
David Lloyd created ELY-895:
-------------------------------
Summary: AuthenticationConfiguration equals() and hashCode()
Key: ELY-895
URL: https://issues.jboss.org/browse/ELY-895
Project: WildFly Elytron
Issue Type: Bug
Components: Authentication Client
Reporter: David Lloyd
Priority: Critical
We need AuthenticationConfiguration to have an equals() and hashCode() contract. Prerequisites to this are:
* Configurations must be commutative i.e. A+B == B+A
* Configurations must strictly eliminate similar items (we have a good start on this)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Kabir Khan resolved WFLY-4937.
------------------------------
Resolution: Done
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions, XTS
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> This feature will allow EAP supported transaction services to react to suspend and resume requests. The supported services are JTA, JTS, WS-AT, and WS-BA.
> After suspend, all the services remain functional. All external requests bound to the existing transactions are allowed in. All external requests requiring new transaction are blocked. All remote transaction management requests, except begin, are allowed in.
> After resume, all requests are allowed in.
> After suspend timeout, all services must shutdown.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-764) Delete the dependency to commons-lang 2 in all poms in Drools and jBPM (use commons-lang 3 instead)
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-764?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer commented on DROOLS-764:
-----------------------------------------------
hmm - seems not to be so easy, when changing this in
https://github.com/droolsjbpm/guvnor/blob/master/guvnor-ala/guvnor-ala-sp...
https://github.com/droolsjbpm/guvnor/blob/master/guvnor-ala/guvnor-ala-di...
it doesn't build because of:
Found 2 illegal transitive type dependencies in artifact 'org.guvnor:guvnor-ala-spi:jar:7.0.0-SNAPSHOT':
1.) org.apache.commons.lang.text.StrLookup
2.) org.apache.commons.lang.text.StrSubstitutor
Doing a mvn dependency:tree I see that org.kie:kie-ci:jar:7.0.0-SNAPSHOT brings in dependency to commons-lang.
> Delete the dependency to commons-lang 2 in all poms in Drools and jBPM (use commons-lang 3 instead)
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-764
> URL: https://issues.jboss.org/browse/DROOLS-764
> Project: Drools
> Issue Type: Task
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Minor
>
> Make an inventory of all modules that still use commons-lang and ask their owners to replace the commons-lang 2 usage with commons-lang 3.
> See recipe below how they can quickly do that.
> Once all our modules are upgraded, see if we can remove the commons-lang 2 dependency as much as possible (including the ip-bom hopefully).
> {code}
> Currently we have commons-lang 2.6 and 3.1 in our classpath
> (which is not a problem because they use a different package namespace).
> Nevertheless, having it twice doesn't look good
> and 2.6 might miss security fixes.
> Luckily upgrading is easy (it took me 15 minutes for optaplanner):
> 1) Replace:
> <dependency>
> <groupId>commons-lang</groupId>
> <artifactId>commons-lang</artifactId>
> </dependency>
> with
> <dependency>
> <groupId>org.apache.commons</groupId>
> <artifactId>commons-lang3</artifactId>
> </dependency>
> (Both are already in the ip-bom, so no need to worry about <version>)
> 2) Replace "import org.apache.commons.lang."
> with "import org.apache.commons.lang3."
> I had about 170 occurrences.
> 3) Compile. If you have a compile error, look for that class on:
> https://commons.apache.org/proper/commons-lang/article3_0.html
> I only had 1 error. Replacing "StringEscapeUtils.escapeHtml(s)"
> with "StringEscapeUtils.ESCAPE_HTML4.translate(s)" fixed that.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7953) Coverity: default platform encoding used in DefaultSingleSignOnSessionFactory
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7953?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7953:
-----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Coverity: default platform encoding used in DefaultSingleSignOnSessionFactory
> -----------------------------------------------------------------------------
>
> Key: WFLY-7953
> URL: https://issues.jboss.org/browse/WFLY-7953
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Critical
>
> Coverity static-analysis scan found a String to byte conversion (4xoccurences of {{getBytes()}}) with default platform encoding in the DefaultSingleSignOnSessionFactory method.
> Following code
> {code:java|title=DefaultSingleSignOnSessionFactory.java}
> @Override
> public String createLogoutParameter(String sessionId) {
> try {
> Signature signature = Signature.getInstance(DEFAULT_SIGNATURE_ALGORITHM);
> signature.initSign(this.privateKey);
> Base64.Encoder urlEncoder = Base64.getUrlEncoder();
> return sessionId + "." + ByteIterator.ofBytes(urlEncoder.encode(ByteIterator.ofBytes(sessionId.getBytes()).sign(signature).drain())).asUtf8String().drainToString();
> } catch (NoSuchAlgorithmException | InvalidKeyException e) {
> throw new IllegalStateException(e);
> }
> }
>
> @Override
> public String verifyLogoutParameter(String parameter) {
> String[] parts = parameter.split("\\.");
> if (parts.length != 2) {
> throw new IllegalArgumentException(parameter);
> }
> try {
> String localSessionId = ByteIterator.ofBytes(parts[0].getBytes()).asUtf8String().drainToString();
> Signature signature = Signature.getInstance(DEFAULT_SIGNATURE_ALGORITHM);
> signature.initVerify(this.certificate);
> signature.update(localSessionId.getBytes());
> Base64.Decoder urlDecoder = Base64.getUrlDecoder();
> if (!ByteIterator.ofBytes(urlDecoder.decode(parts[1].getBytes())).verify(signature)) {
> throw log.httpMechSsoInvalidLogoutMessage(localSessionId);
> }
> return localSessionId;
> } catch (NoSuchAlgorithmException | InvalidKeyException e) {
> throw new IllegalStateException(e);
> } catch (SignatureException e) {
> throw new IllegalArgumentException(parameter, e);
> }
> }
> {code}
> The encoding should be specified as argument.
> Setting with high priority, because once default platform encoding UTF-16 will be set, funcionality do not need to work as intended. Especially when combined with {{asUtf8String()}}, which implies specifying default encoding UTF-8.
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=86758...
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=86758...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months