November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9539) wsconsume.sh does not support the -secmgr setting properly

by R Searls (JIRA)

[ https://issues.jboss.org/browse/WFLY-9539?page=com.atlassian.jira.plugin.... ] R Searls commented on WFLY-9539: -------------------------------- The documentation for -segmgr states that setting env var SECMGR=true will set this flag. scripts standalone.sh, appclient.sh, domain.sh, common.ps1, and appclient.sh all check for old value and present msg, {code:java} -Djava.security.manager) echo "ERROR: The use of -Djava.security.manager has been removed. Please use the -secmgr command line argument or SECMGR=true environment variable." {code} This utility should probably have the same check and report the same message. In addition it should check for and use env var SECMGR. > wsconsume.sh does not support the -secmgr setting properly > ---------------------------------------------------------- > > Key: WFLY-9539 > URL: https://issues.jboss.org/browse/WFLY-9539 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 10.0.0.Final > Reporter: R Searls > Assignee: Tomaz Cerar > > wsconsume.sh, and wsconsume.bat does not properly support the -secmgr flag in the > generated command. Changes to jboss-module.jar requires the -secmgr flag be positioned > immediately after the jboss-module.jar declaration. > {code:java} > eval \"$JAVA\" $JAVA_OPTS \ > -classpath \""$JBOSS_CLASSPATH"\" \ > org.jboss.modules.Main \ > -secmgr \ > -mp \""$JBOSS_HOME"/modules\" \ > org.jboss.ws.tools.wsconsume \ > '"$@"' > {code} > This value is pass to this utility via the JAVA_OPTS env variable. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9538) wsprovide.sh does not support the -secmgr setting properly

by R Searls (JIRA)

[ https://issues.jboss.org/browse/WFLY-9538?page=com.atlassian.jira.plugin.... ] R Searls commented on WFLY-9538: -------------------------------- The documentation for -segmgr states that setting env var SECMGR=true will set this flag. scripts standalone.sh, appclient.sh, domain.sh, common.ps1, and appclient.sh all check for old value and present msg, {code:java} -Djava.security.manager) echo "ERROR: The use of -Djava.security.manager has been removed. Please use the -secmgr command line argument or SECMGR=true environment variable." {code} This utility should probably have the same check and report the same message. In addition it should check for and use env var SECMGR. > wsprovide.sh does not support the -secmgr setting properly > ---------------------------------------------------------- > > Key: WFLY-9538 > URL: https://issues.jboss.org/browse/WFLY-9538 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 10.0.0.Final > Reporter: R Searls > Assignee: Tomaz Cerar > > wsprovide.sh, wsprovide.bat does not generate the cmd with the -secmgr flag in the > proper position. Changes to jboss-module.jar requires -segmgr to reside just after > the jboss-module.jar reference like this. > {code:java} > eval \"$JAVA\" $JAVA_OPTS \ > -jar \""$JBOSS_HOME"/jboss-modules.jar\" \ > *-secmgr \ * > -mp \""$JBOSS_HOME"/modules\" \ > org.jboss.ws.tools.wsprovide \ > '"$@"' > {code} > Current the old style and this new style value is passed in via the JAVA_OPTS env var. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2673) HTTP redirect if both http and https socket-binding is configured for http-interface

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2673?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2673: ------------------------------------- Issue Type: Feature Request (was: Enhancement) > HTTP redirect if both http and https socket-binding is configured for http-interface > ------------------------------------------------------------------------------------ > > Key: WFCORE-2673 > URL: https://issues.jboss.org/browse/WFCORE-2673 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ondrej Lukas > > In case when both http and https socket-binding is configured for management http-interface and http port is accessed then server tries to redirect automatically to https port. Access http is not possible. > It causes that it is impossible to connect to http-interface with clients which do not supports https (even if http port is provided by application server), i.e. following ModelControllerClient is not able to connect to http-interface when both http and https socket-binding is configured: > {code} > ModelControllerClient client = ModelControllerClient.Factory > .create(new ModelControllerClientConfiguration.Builder() > .setProtocol("remote+http") > .setPort(9990) > .setHostName("localhost") > .setConnectionTimeout(10000).build()) > {code} > See: > {code} > curl -v -H 'Upgrade: jboss-remoting' http://localhost:9990 > * Rebuilt URL to: http://localhost:9990/ > * Hostname was NOT found in DNS cache > * Trying 127.0.0.1... > * Connected to localhost (127.0.0.1) port 9990 (#0) > > GET / HTTP/1.1 > > User-Agent: curl/7.38.0 > > Host: localhost:9990 > > Accept: */* > > Upgrade: jboss-remoting > > > < HTTP/1.1 302 Found > < Connection: keep-alive > < Location: https://localhost:9993/ > < Content-Length: 0 > < Date: Thu, 13 Apr 2017 11:59:56 GMT > < > * Connection #0 to host localhost left intact > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1358) Container is not cleaning up container-managed JMSContext

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1358?page=com.atlassian.jira.plugin... ] Jiri Ondrusek updated JBJCA-1358: --------------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/642 > Container is not cleaning up container-managed JMSContext > --------------------------------------------------------- > > Key: JBJCA-1358 > URL: https://issues.jboss.org/browse/JBJCA-1358 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.4.3.Final > Environment: JBoss-EAP-7.0.0 > JDK 1.8 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > The container is not cleaning up container managed JMSContext, causing a connection leak. > The JMS 2.0 API doc[1] states the following : > <quote> > Applications running in the Java EE web and EJB containers may alternatively inject a JMSContext into their application using the @Inject annotation. A JMSContext that is created in this way is described as being container-managed. A container-managed JMSContext will be closed automatically by the container. > </quote> > However the JCA's CacheConnectionManager (CCM) complains a connection leak if the application didn't explicitly close the JMSContext, which is not required for container managed JMSContext. > [1] http://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1358) Container is not cleaning up container-managed JMSContext

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1358?page=com.atlassian.jira.plugin... ] Jiri Ondrusek commented on JBJCA-1358: -------------------------------------- Problem is happening inironjacamar 1.4.6.Final-redhat-1. Problem is caused by CCM. CCM is trying to close unclosed connections in beforeCompletion phase. It should be done in afterCompletion -> at this time is transaction commited or rolled back. > Container is not cleaning up container-managed JMSContext > --------------------------------------------------------- > > Key: JBJCA-1358 > URL: https://issues.jboss.org/browse/JBJCA-1358 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.4.3.Final > Environment: JBoss-EAP-7.0.0 > JDK 1.8 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > The container is not cleaning up container managed JMSContext, causing a connection leak. > The JMS 2.0 API doc[1] states the following : > <quote> > Applications running in the Java EE web and EJB containers may alternatively inject a JMSContext into their application using the @Inject annotation. A JMSContext that is created in this way is described as being container-managed. A container-managed JMSContext will be closed automatically by the container. > </quote> > However the JCA's CacheConnectionManager (CCM) complains a connection leak if the application didn't explicitly close the JMSContext, which is not required for container managed JMSContext. > [1] http://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1358) Container is not cleaning up container-managed JMSContext

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1358?page=com.atlassian.jira.plugin... ] Jiri Ondrusek edited comment on JBJCA-1358 at 11/9/17 8:44 AM: --------------------------------------------------------------- Problem is happening inironjacamar 1.4.6.Final-redhat-1. Problem is caused also by CCM. CCM is trying to close unclosed connections in beforeCompletion phase. It should be done in afterCompletion -> at this time is transaction commited or rolled back. was (Author: jondruse): Problem is happening inironjacamar 1.4.6.Final-redhat-1. Problem is caused by CCM. CCM is trying to close unclosed connections in beforeCompletion phase. It should be done in afterCompletion -> at this time is transaction commited or rolled back. > Container is not cleaning up container-managed JMSContext > --------------------------------------------------------- > > Key: JBJCA-1358 > URL: https://issues.jboss.org/browse/JBJCA-1358 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.4.3.Final > Environment: JBoss-EAP-7.0.0 > JDK 1.8 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > The container is not cleaning up container managed JMSContext, causing a connection leak. > The JMS 2.0 API doc[1] states the following : > <quote> > Applications running in the Java EE web and EJB containers may alternatively inject a JMSContext into their application using the @Inject annotation. A JMSContext that is created in this way is described as being container-managed. A container-managed JMSContext will be closed automatically by the container. > </quote> > However the JCA's CacheConnectionManager (CCM) complains a connection leak if the application didn't explicitly close the JMSContext, which is not required for container managed JMSContext. > [1] http://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1358) Container is not cleaning up container-managed JMSContext

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1358?page=com.atlassian.jira.plugin... ] Jiri Ondrusek moved JBEAP-13747 to JBJCA-1358: ---------------------------------------------- Project: IronJacamar (was: JBoss Enterprise Application Platform) Key: JBJCA-1358 (was: JBEAP-13747) Workflow: classic default workflow (was: CDW with loose statuses v1) Component/s: (was: EE) (was: EJB) (was: JMS) Affects Version/s: WildFly/IronJacamar 1.4.3.Final (was: 7.0.0.GA) > Container is not cleaning up container-managed JMSContext > --------------------------------------------------------- > > Key: JBJCA-1358 > URL: https://issues.jboss.org/browse/JBJCA-1358 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.4.3.Final > Environment: JBoss-EAP-7.0.0 > JDK 1.8 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > The container is not cleaning up container managed JMSContext, causing a connection leak. > The JMS 2.0 API doc[1] states the following : > <quote> > Applications running in the Java EE web and EJB containers may alternatively inject a JMSContext into their application using the @Inject annotation. A JMSContext that is created in this way is described as being container-managed. A container-managed JMSContext will be closed automatically by the container. > </quote> > However the JCA's CacheConnectionManager (CCM) complains a connection leak if the application didn't explicitly close the JMSContext, which is not required for container managed JMSContext. > [1] http://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9541) Storing a LinkedHashMap subclass in the session breaks replication.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9541?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-9541: ----------------------------------- Another possibility which is compatible with the serialization specification is to provide a replacement class which is instantiated using a (preferably package-private) [writeRepace|https://docs.oracle.com/javase/8/docs/platform/serialization/...] method on the special class, which returns an instance of a {{Serializable}} or {{Externalizable}} class which in turn also has a [readResolve|https://docs.oracle.com/javase/8/docs/platform/serialization/...] method on it that returns an instance of the original class. > Storing a LinkedHashMap subclass in the session breaks replication. > ------------------------------------------------------------------- > > Key: WFLY-9541 > URL: https://issues.jboss.org/browse/WFLY-9541 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Alpha1 > Environment: Tested on JDK 1.8.0_152 on OS X 10.12 > Reporter: Klaasjan Brand > Assignee: Paul Ferraro > > Context: trying to get one of our applications to work with Wildfly session replication. > After trying out a build from the Wildfly master branch to test another bug I submitted I noticed another issue which works fine in the Wildfly 11 release. > Our application has a custom LinkedHashMap subclass (MostRecentlyUsedMap from the Wicket framework) which it stores in the session. It also keeps a reference to the subclass since that one has a few extra fields. > When marshalling the session the MostRecentlyUsedMap is converted to a LinkedHashMap. When unmarshalling the session this causes an error since the field is of the subclass type. > This behaviour is new in WF 12 and is related to this commit: > https://github.com/wildfly/wildfly/commit/143527f595206c5f2bf037b47c797f0... > (fix for the WFLY-9497 issue). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2124) 6.5.x Decision table fails to handle predicate

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2124?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2124: -------------------------------- Tester: Jozef Marko > 6.5.x Decision table fails to handle predicate > ---------------------------------------------- > > Key: DROOLS-2124 > URL: https://issues.jboss.org/browse/DROOLS-2124 > Project: Drools > Issue Type: Bug > Components: decision tables > Reporter: Toni Rikkola > Assignee: Mario Fusco > > Create a dtable. > Add Condition. > Create New fact pattern > Select Calculation type: Predicate > Add row ( if you did not already have one ) > Add something into the predicate field. I used "gggggg" > Open source tab > Try to open Editor tab > Can't go back to Editor tab. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2124) 6.5.x Decision table fails to handle predicate

by Toni Rikkola (JIRA)

Toni Rikkola created DROOLS-2124: ------------------------------------ Summary: 6.5.x Decision table fails to handle predicate Key: DROOLS-2124 URL: https://issues.jboss.org/browse/DROOLS-2124 Project: Drools Issue Type: Bug Components: decision tables Reporter: Toni Rikkola Assignee: Mario Fusco Create a dtable. Add Condition. Create New fact pattern Select Calculation type: Predicate Add row ( if you did not already have one ) Add something into the predicate field. I used "gggggg" Open source tab Try to open Editor tab Can't go back to Editor tab. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2017