[JBoss JIRA] (WFLY-6297) Identify problems introduced with new JDK9 versioning scheme
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6297?page=com.atlassian.jira.plugin.... ]
Richard Opalka commented on WFLY-6297:
--------------------------------------
After source code review we identified problems with new JDK9 versioning scheme in these classes:
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/apt/util/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/tool/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/apache/cxf/main/cxf-core-3.1.4.jar', class 'org/apache/cxf/common/util/ClassHelper', contains string [java.version]
modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.1.2.Final.jar', class 'org/apache/log4j/helpers/Loader', contains string [java.version]
> Identify problems introduced with new JDK9 versioning scheme
> ------------------------------------------------------------
>
> Key: WFLY-6297
> URL: https://issues.jboss.org/browse/WFLY-6297
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Affects Versions: 10.0.0.Final
> Reporter: Richard Opalka
> Assignee: Richard Opalka
>
> JDK9 will introduce new versioning scheme described here:
> http://openjdk.java.net/projects/verona/
> We need to identify WildFly components that are realying on
> these properties.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6297) Identify problems introduced with new JDK9 versioning scheme
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6297?page=com.atlassian.jira.plugin.... ]
Richard Opalka updated WFLY-6297:
---------------------------------
Comment: was deleted
(was: After source code review we identified problems with new JDK9 versioning scheme in these classes:
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/apt/util/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/tool/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/apache/cxf/main/cxf-core-3.1.4.jar', class 'org/apache/cxf/common/util/ClassHelper', contains string [java.version]
modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.1.2.Final.jar', class 'org/apache/log4j/helpers/Loader', contains string [java.version])
> Identify problems introduced with new JDK9 versioning scheme
> ------------------------------------------------------------
>
> Key: WFLY-6297
> URL: https://issues.jboss.org/browse/WFLY-6297
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Affects Versions: 10.0.0.Final
> Reporter: Richard Opalka
> Assignee: Richard Opalka
>
> JDK9 will introduce new versioning scheme described here:
> http://openjdk.java.net/projects/verona/
> We need to identify WildFly components that are realying on
> these properties.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6283:
------------------------------------
Harold, when you started the app server, did you enable clustering (e.g. "/standalone.sh -c standalone-ha.xml")?
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ]
Tom Fonteyne edited comment on WFCORE-1417 at 3/1/16 7:54 AM:
--------------------------------------------------------------
not sure what the correct solution would be....
either for every applicable connect:
{code:java}
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
ctx = null;
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
ctx = null;
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
{code}
or:
{code:java}
public void terminateSession() {
try {
ctx.terminateSession();
} finally {
ctx = null;
}
}
{code}
and for every applicable connect:
{code:java}
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
terminateSession();
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
terminateSession();
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
{code}
was (Author: tfonteyn):
not sure what the correct solution would be....
either for every applicable connect:
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
ctx = null;
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
ctx = null;
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
or:
public void terminateSession() {
try {
ctx.terminateSession();
} finally {
ctx = null;
}
}
and for every applicable connect:
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
terminateSession();
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
terminateSession();
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
> org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1417
> URL: https://issues.jboss.org/browse/WFCORE-1417
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.CR1
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java
> public void connect() {
> checkAlreadyConnected();
> try {
> ctx = CommandContextFactory.getInstance().newCommandContext();
> ctx.connectController();
> } catch (CliInitializationException e) {
> throw new IllegalStateException("Unable to initialize command context.", e);
> } catch (CommandLineException e) {
> throw new IllegalStateException("Unable to connect to controller.", e);
> }
> }
> also applicable to the other connects of course.
> If the connection fails in the connect method, a subsequent connect will hit:
> private void checkAlreadyConnected() {
> if (ctx != null) throw new IllegalStateException("Already connected to server.");
> }
> and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed.
> ergo, upon failure in connect, the ctx should be reset to avoid this
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ]
Tom Fonteyne reassigned WFCORE-1417:
------------------------------------
Assignee: Alexey Loubyansky (was: Tom Fonteyne)
> org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1417
> URL: https://issues.jboss.org/browse/WFCORE-1417
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.CR1
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java
> public void connect() {
> checkAlreadyConnected();
> try {
> ctx = CommandContextFactory.getInstance().newCommandContext();
> ctx.connectController();
> } catch (CliInitializationException e) {
> throw new IllegalStateException("Unable to initialize command context.", e);
> } catch (CommandLineException e) {
> throw new IllegalStateException("Unable to connect to controller.", e);
> }
> }
> also applicable to the other connects of course.
> If the connection fails in the connect method, a subsequent connect will hit:
> private void checkAlreadyConnected() {
> if (ctx != null) throw new IllegalStateException("Already connected to server.");
> }
> and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed.
> ergo, upon failure in connect, the ctx should be reset to avoid this
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ]
Tom Fonteyne commented on WFCORE-1417:
--------------------------------------
not sure what the correct solution would be....
either for every applicable connect:
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
ctx = null;
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
ctx = null;
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
or:
public void terminateSession() {
try {
ctx.terminateSession();
} finally {
ctx = null;
}
}
and for every applicable connect:
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
terminateSession();
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
terminateSession();
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
> org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1417
> URL: https://issues.jboss.org/browse/WFCORE-1417
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.CR1
> Reporter: Tom Fonteyne
> Assignee: Tom Fonteyne
> Priority: Minor
>
> cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java
> public void connect() {
> checkAlreadyConnected();
> try {
> ctx = CommandContextFactory.getInstance().newCommandContext();
> ctx.connectController();
> } catch (CliInitializationException e) {
> throw new IllegalStateException("Unable to initialize command context.", e);
> } catch (CommandLineException e) {
> throw new IllegalStateException("Unable to connect to controller.", e);
> }
> }
> also applicable to the other connects of course.
> If the connection fails in the connect method, a subsequent connect will hit:
> private void checkAlreadyConnected() {
> if (ctx != null) throw new IllegalStateException("Already connected to server.");
> }
> and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed.
> ergo, upon failure in connect, the ctx should be reset to avoid this
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6257) Allow Narayanas list of XAOrphanFilters to include a check of the status of a transaction locally
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6257?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-6257:
--------------------------------
Description: Narayana has added a check of the action status service to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly. (was: Narayana has added a check of the transaction status manager to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly.)
> Allow Narayanas list of XAOrphanFilters to include a check of the status of a transaction locally
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6257
> URL: https://issues.jboss.org/browse/WFLY-6257
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 11.0.0.Alpha1
>
>
> Narayana has added a check of the action status service to check the status of the transaction with a transaction manager. This needs to be exposed in WildFly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-430) Add HostnameVerifier implementation
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-430:
------------------------------------
Summary: Add HostnameVerifier implementation
Key: ELY-430
URL: https://issues.jboss.org/browse/ELY-430
Project: WildFly Elytron
Issue Type: Feature Request
Components: SSL
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta5
We should at the very least have a sensible default implementation checking the certificate against the host name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months