May 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3805) JGroupsBroadcastGroupConfiguration Serialization Problem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3805: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > JGroupsBroadcastGroupConfiguration Serialization Problem > -------------------------------------------------------- > > Key: WFLY-3805 > URL: https://issues.jboss.org/browse/WFLY-3805 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 9.0.0.CR2 > > > When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3853) Cache PersistenceProviders within the same deployment

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3853?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3853: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Cache PersistenceProviders within the same deployment > ----------------------------------------------------- > > Key: WFLY-3853 > URL: https://issues.jboss.org/browse/WFLY-3853 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 9.0.0.CR2 > > > See wildfly-dev ml discussion [http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html] about calls to PersistenceProviderResolver.getPersistenceProviders() should return a cached list. The cache should be per deployment. > We can probably reuse our PersistenceProviderResolverImpl.persistenceProviderPerClassLoader map, just need to be careful that addDeploymentSpecificPersistenceProvider() is called early before any calls to getPersistenceProviders(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3827) Update Subsystem for PicketLink Console

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3827?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3827: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Update Subsystem for PicketLink Console > --------------------------------------- > > Key: WFLY-3827 > URL: https://issues.jboss.org/browse/WFLY-3827 > Project: WildFly > Issue Type: Enhancement > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 9.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3816) ClassNotFoundException com.ibm.crypto.provider.IBMJCE with IBM JDK

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3816?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3816: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > ClassNotFoundException com.ibm.crypto.provider.IBMJCE with IBM JDK > ------------------------------------------------------------------ > > Key: WFLY-3816 > URL: https://issues.jboss.org/browse/WFLY-3816 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: JBoss AS7 7.2.0.Final, 8.1.0.Final > Environment: Linux / Aix ; IBM JDK 1.6 > Reporter: Yannick Lorenzati > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 9.0.0.CR2 > > > I use Jboss AS 7.2.0 with IBM JDK 1.6 > One of my applications try to load the security provider com.ibm.crypto.provider.IBMJCE but I got an ClassNotFoundException. > I think it’s because in the ibm.jdk module.xml we need to add the package of the security provider like this > <module xmlns="urn:jboss:module:1.1" name="ibm.jdk"> > <resources> > </resources> > <dependencies> > <system export="true"> > <paths> > <path name="com/ibm"/> > <path name="com/ibm/jvm"/> > <path name="com/ibm/jvm/io"/> > <path name="com/ibm/jvm/util"/> > <path name="com/ibm/match"/> > <path name="com/ibm/misc"/> > <path name="com/ibm/net"/> > <path name="com/ibm/nio"/> > <path name="com/ibm/nio/ch"/> > <path name="com/ibm/security/auth"/> > <path name="com/ibm/security/bootstrap"/> > <path name="com/ibm/security/auth/module"/> > <path name="com/ibm/security/util"/> > </paths> > </system> > </dependencies> > </module> > We need to add this > <path name="com/ibm/crypto"/> > <path name="com/ibm/crypto/provider"/> > Can't do a pull request at work, but i hope this help -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3872: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > -------------------------------------------------------------------------------------------- > > Key: WFLY-3872 > URL: https://issues.jboss.org/browse/WFLY-3872 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Stuart Douglas > Fix For: 9.0.0.CR2 > > > Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often. > Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3860) Improve dependency handling in clustering/infinispan subsystem tests

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3860?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3860: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Improve dependency handling in clustering/infinispan subsystem tests > -------------------------------------------------------------------- > > Key: WFLY-3860 > URL: https://issues.jboss.org/browse/WFLY-3860 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 9.0.0.CR2 > > > The subsystem tests in clustering/infinispan are not configured to use a controller operating in --admin-only mode, but they are also not doing all the needed setup to have needed services and resources (core, jmx, jgroups) available for when the services they add are started. > This is fragile, because all sorts of stuff is failing when things are getting launched, but the tests are not noticing that. That's ok right now, but it could lead to missing regressions. > Also, the changes I'm making for WFCORE-102 mean these problems will no longer go unnoticed and the tests will fail. > I plan to: > 1) Shifts tests to using --admin-only in cases where the tests are clearly not testing anything related to runtime execution; i.e. they are just testing model. > 2) For OperationSequencesTestCase and OperationsTestCase, where there is some validation of runtime behavior going on (explicit in some places; in others perhaps expected, perhaps not) I'm going to switch the tests to a more focused config file that: > a) Only uses local caches, to avoid pulling in requirements for jgroups things that are not present. (I see no indication any of the tests are testing anything not present with local caches.) > b) Uses start="LAZY". This means services will get registered, but not started. Not starting avoids detection of various missing dependencies, including a ModuleLoader dependency that I can't figure out how to satisfy. > The tests can't be trying to validate any behavior when services start, because they've never been able to start. So LAZY is fine. Some tests do seem to be looking for problem related to service conflicts as resources are added/removed. These tests are still valid, because service conflicts happen as soon as services are installed, whether or not the services need to start. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3859) Improve ChannelInstanceResourceDefinition.addChannelProtocolMetricsRegistrationStep

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3859?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3859: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Improve ChannelInstanceResourceDefinition.addChannelProtocolMetricsRegistrationStep > ----------------------------------------------------------------------------------- > > Key: WFLY-3859 > URL: https://issues.jboss.org/browse/WFLY-3859 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 9.0.0.CR2 > > > While debugging a test, I noticed this in the test's console output: > ERROR: WFLYCTL0013: Operation ("some_operation_name") failed - address: ([("subsystem" => "jgroups")]) - failure description: "WFLYCTL0216: Management resource '[(\"subsystem\" => \"jgroups\")]' not found" > Sep 16, 2014 9:29:35 AM org.jboss.as.controller.AbstractOperationContext executeStep > That "some_operation_name" visible to users isn't so good. > A simple fix is to use a more meaningful name. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3854) Make it build & work on JDK9

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3854?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3854: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Make it build & work on JDK9 > ---------------------------- > > Key: WFLY-3854 > URL: https://issues.jboss.org/browse/WFLY-3854 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 9.0.0.CR2 > > > Currently wildfly doesn't build on JDK9 mostly because of passing -XX:MaxPermSize=xxx > It was deprecated in 8 and removed in 9. > We should add two profiles that would take care of that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3921) Support direct JMX mbeans as dependecies

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3921?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3921: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Support direct JMX mbeans as dependecies > ---------------------------------------- > > Key: WFLY-3921 > URL: https://issues.jboss.org/browse/WFLY-3921 > Project: WildFly > Issue Type: Feature Request > Components: JMX > Affects Versions: 9.0.0.Alpha1 > Reporter: Ales Justin > Assignee: Ales Justin > Fix For: 9.0.0.CR2 > > > We should be able to depend on existing mbeans from jboss-service.xml. > (e.g. mbeans registered directly from JMX API) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3911) EJB timer service security manager issue

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3911?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3911: ------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > EJB timer service security manager issue > ---------------------------------------- > > Key: WFLY-3911 > URL: https://issues.jboss.org/browse/WFLY-3911 > Project: WildFly > Issue Type: Bug > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 9.0.0.CR2 > > > The file-backed timer service reads files without privileged context, causing security manager failures when loading persisted timers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 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 May 2015