September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5290) Adding JGroups stack seems to freeze the UI

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5290?page=com.atlassian.jira.plugin.... ] Kabir Khan reassigned WFLY-5290: -------------------------------- Assignee: Kabir Khan (was: Paul Ferraro) > Adding JGroups stack seems to freeze the UI > ------------------------------------------- > > Key: WFLY-5290 > URL: https://issues.jboss.org/browse/WFLY-5290 > Project: WildFly > Issue Type: Bug > Components: Clustering, Domain Management > Reporter: Jan Kašík > Assignee: Kabir Khan > Priority: Critical > Fix For: 10.0.0.Final > > > Adding new JGroups stack with randomly chosen (non existing) socket binding name results in web console freeze. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5433) CommandDispatcher can throw InvalidClassException if command class is not available

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-5433: ---------------------------------- Summary: CommandDispatcher can throw InvalidClassException if command class is not available Key: WFLY-5433 URL: https://issues.jboss.org/browse/WFLY-5433 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR2 Reporter: Paul Ferraro Assignee: Paul Ferraro When CommandDispatcher is used by a deployment, the command class might not be available if the deployment is not deployed. Normally, this is prevented by returning a NoSuchService response if the service is unknown, however, this happens *after* the command is unmarshalled. This check should happen before we attempt to unmarshall the command, avoiding unnecessary InvalidClassException. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5340) Unable to specify module when specifying custom JACC policy class.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5340: ----------------------------------------------- Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from ASSIGNED to POST > Unable to specify module when specifying custom JACC policy class. > ------------------------------------------------------------------ > > Key: WFLY-5340 > URL: https://issues.jboss.org/browse/WFLY-5340 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Beta2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.CR1 > > > It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module. > From the JACC specification: - > _For each JRE of a J2EE 1.4 or later version Java EE application server, if the > system property > “javax.security.jacc.policy.provider > ” is defined, > the application server must construct an > instance of the class identified by the > system property, confirm that the > resulting object is an instance of > java.security.Policy, > and set, by calling the > java.security.Policy.setPolicy > method, the resulting object as the > corresponding Policy object u > sed by the JRE. _ > The specification only specifies that the system property identifies the class, it does not specify how. > In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1844) Remove shared transport

by Rich DiCroce (JIRA)

[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ] Rich DiCroce commented on JGRP-1844: ------------------------------------ The situation I am in is that two applications share some Infinispan caches, but also have some of their own independent caches. The short explanation is that I have to create three separate cache managers (one shared, one for each application), each of which requires its own JGroups channel. Infinispan assumes that every node in the view is participating in the cache manager, which isn't true for the app-specific cache managers when using a fork channel. That is arguably more of an Infinispan problem, and I'm going to file some issues in the Infinispan JIRA for those, but I don't know if or when those issues will ever be resolved. Shared transport is a useful workaround in the meantime. I also have my own fork channel that is used by only one of the two applications, and I need to be able to determine a coordinator within that subset of members. JGroups currently doesn't do anything to help with that, so instead of forking the channel that is shared by both applications, I'm forking the app-specific channel. It would be nice if JGroups did something for applications using fork channels, so the application can easily determine which cluster members are participating in the fork. Alternatively, is it possible to put the FORK protocol lower in the stack, below the GMS protocol? Then forks would have their own separate views. I haven't tried that but I doubt it would work based on what I've read. > Remove shared transport > ----------------------- > > Key: JGRP-1844 > URL: https://issues.jboss.org/browse/JGRP-1844 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2]. > Here's my reasoning: > * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller > * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared > * TUNNEL doesn't work with shared transports (throws an exception) > * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used > * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste > Thoughts ? My +100 for removing shared transports in 4.0... > [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport > [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3351) WildFly self-monitoring (history storage + REST API + web console plugin)

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3351?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-3351: ----------------------------------- Assignee: (was: James Perkins) > WildFly self-monitoring (history storage + REST API + web console plugin) > ------------------------------------------------------------------------- > > Key: WFLY-3351 > URL: https://issues.jboss.org/browse/WFLY-3351 > Project: WildFly > Issue Type: Feature Request > Components: Logging > Reporter: Ondrej Zizka > Priority: Optional > > Would be nice if WildFly had it's optional own submodule which would monitor the AS, store the data, and allow it's retrieval later through REST API. Also, the console could have a plugin to read and display these data. > This was discussed some time ago as one of requirements by different parties - JON, JBDS, end users. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5340) Unable to specify module when specifying custom JACC policy class.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5340: ----------------------------------------------- Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from NEW to ASSIGNED > Unable to specify module when specifying custom JACC policy class. > ------------------------------------------------------------------ > > Key: WFLY-5340 > URL: https://issues.jboss.org/browse/WFLY-5340 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Beta2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.CR1 > > > It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module. > From the JACC specification: - > _For each JRE of a J2EE 1.4 or later version Java EE application server, if the > system property > “javax.security.jacc.policy.provider > ” is defined, > the application server must construct an > instance of the class identified by the > system property, confirm that the > resulting object is an instance of > java.security.Policy, > and set, by calling the > java.security.Policy.setPolicy > method, the resulting object as the > corresponding Policy object u > sed by the JRE. _ > The specification only specifies that the system property identifies the class, it does not specify how. > In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2982) refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2982?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-2982: ------------------------------- Fix Version/s: (was: 10.0.0.Final) > refactor two phase persistence unit services (PhaseOnePersistenceUnitServiceImpl + PersistenceUnitServiceImpl) into one service > ------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2982 > URL: https://issues.jboss.org/browse/WFLY-2982 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 8.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > > Related feedback from https://github.com/wildfly/wildfly/pull/4722: > {quote} > This is asymetrical, so if this service , and phase one are stopped, and then phase 1 is started again, phase 2 will appear started. The side effects seem minor though > {quote} > {quote} > We have a long term goal to somehow verify every service can be stopped and started with the expected effect. Right now many of our services are not restartable which makes potential new features like partial deployment standby hard to achieve. So Im just offering pointers whenever I see lifecycle symmetry issues. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

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

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3853?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-3853: ------------------------------- Fix Version/s: (was: 10.0.0.Final) > 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 > > 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.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-5319: ------------------------------- Fix Version/s: (was: 10.0.0.Final) > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5425) http-listener requires 'https' socket-binding, part 2

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5425?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-5425: ------------------------------ Fix Version/s: 9.0.0.Beta2 > http-listener requires 'https' socket-binding, part 2 > ----------------------------------------------------- > > Key: WFLY-5425 > URL: https://issues.jboss.org/browse/WFLY-5425 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Vsevolod Golovanov > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta2 > > > Continuing WFLY-2836. > Is there a way to override {{http-listener}}'s {{redirect-socket}} attribute default value ("https") to be null? > {quote}This is just default value, looking at the downside of not having default value for redirect-socket would be that people would not configure it, which would result in problems when having apps that require secure transport.{quote} > Our app doesn't require secure transport. > {code}redirect-socket=""{code} > results in > {noformat} > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[956,166] > Message: "JBAS014704: '' is an invalid value for parameter redirect-socket. Values must have a minimum length of 1 characters" > {noformat} > This: > {code}redirect-socket="null"{code} > treats it literally: > {noformat} > ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.someapp-http-listener is missing [jboss.binding.null]"]} > {noformat} > So we're forced to have a https socket-binding. Which is not a "just define some binding" problem. It's a "negotiate with customers&sysadmins/document it/provide options to configure it" problem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 September 2015