December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5298) JASPIC verifyResponse is not called if proactive authentication is not in use

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5298?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5298. ---------------------------- > JASPIC verifyResponse is not called if proactive authentication is not in use > ----------------------------------------------------------------------------- > > Key: WFLY-5298 > URL: https://issues.jboss.org/browse/WFLY-5298 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 10.0.0.Beta2 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 10.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4811) Add batch-jberet subsystem to replace the original batch subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4811?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4811. ---------------------------- > Add batch-jberet subsystem to replace the original batch subsystem > ------------------------------------------------------------------ > > Key: WFLY-4811 > URL: https://issues.jboss.org/browse/WFLY-4811 > Project: WildFly > Issue Type: Enhancement > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > Fix For: 10.0.0.Beta1 > > > The original batch subsystem will not work well with capabilities and requirements. It's also fairly limited in the validation it can offer for the job repositories. > Current model: > {code} > { > "outcome" => "success", > "result" => { > "job-repository-type" => "in-memory", > "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, > "thread-factory" => undefined, > "thread-pool" => {"batch" => { > "keepalive-time" => { > "time" => 30L, > "unit" => "SECONDS" > }, > "max-threads" => 10, > "name" => "batch", > "thread-factory" => undefined > }} > } > } > {code} > The {{job-repository-type}} will be removed as well as the {{job-repository=jdbc}}. A new {{jdbc-job-repository}} and {{in-memory-job-repository}} resource will be added. There will also be a {{default-job-repository}} which will accept a name from one of the defined job repositories. > The {{jndi-name}} will no longer be used and a {{data-source}} name will be used for the JDBC job repository. For example resource value might be {{ExampleDS}}. > A new deployment descriptor will be added to allow a user to defined a job repository configured on the subsystem. > Due to these changes the persisted XML will likely need some small alterations. Mainly ensuring a name attribute is persisted and multiple repositories are allowed to be defined. > The current batch subsystem will remain. It will allow the server to boot with old configurations, but the default with be the new {{batch-jberet}} subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4799) cancelled ejb timers persist in data/timer-service-data

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4799?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4799. ---------------------------- > cancelled ejb timers persist in data/timer-service-data > ------------------------------------------------------- > > Key: WFLY-4799 > URL: https://issues.jboss.org/browse/WFLY-4799 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.CR2 > Environment: linux 4.0.4-303.fc22.x86_64, java jdk1.8.0_45 and wildfly-9.0.0.CR2 > Reporter: John Whitley > Assignee: jaikiran pai > Labels: jboss > Fix For: 9.0.0.Final, 10.0.0.Alpha4 > > Attachments: timertest.tgz > > > I have a Singleton bean which creates a ejb.timer on deployment. Before doing so it cancels any existing timers previously created by the bean for completeness. > In wildfly 8 the cancelled timers were removed from data/timer-service-data/'bean'. In wildfly 9 CR2, they stay in data/timer-service-data/'bean' and appear to be re-instated on re-deployment -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4697) EJBClient access to SFSBs does not play well with clean shutdown

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4697?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4697. ---------------------------- > EJBClient access to SFSBs does not play well with clean shutdown > ---------------------------------------------------------------- > > Key: WFLY-4697 > URL: https://issues.jboss.org/browse/WFLY-4697 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB, Remoting > Affects Versions: 10.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Fix For: 10.0.0.Alpha4 > > > The clean shutdown mechanism allows EJB and web applications to make use of shutdown interceptors to allow the application server to refuse requests when a server is in the process of shutting down. These interceptors are tied to the processing of EJB invocations and web requests. > In the case of EJBCLient invocations, they arrive at the remoting connector, and undergo some preliminary processing before being sent to the EJB interface in question. When a server is shutting down, EJBCLient invocations can arrive at the RemoteConnector and start processing, even when the EJB interface has been locked down, so to speak. > I am seeing various types of exceptions arising from this preliminary processing (e.g. NPE on DeploymentRepository lookups) and these get returned to the client as exceptions on the SFSB invocation, before even reaching the SFSB interceptors. > If the EJBCLient is running in a managed transaction context, these returned exceptions will case the SFSB to be discarded (as the SFSB invocation is considered failed with the exception returned) and the transaction will attempt to rollback. If the rollback processing fails (because the original node in the transaction is down the bean gets removed anyway. The SFSB session state is lost, even if there is another node in the cluster which can support the invocation. > In short, it looks as though the clean shutdown mechanism needs to be used to also lock down the processing of EJBCLient invocations in some way. > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4594) Move messaging subsystem to legacy/

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4594?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4594. ---------------------------- > Move messaging subsystem to legacy/ > ----------------------------------- > > Key: WFLY-4594 > URL: https://issues.jboss.org/browse/WFLY-4594 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1247) graceful shutdown

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-1247?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-1247. ---------------------------- > graceful shutdown > ----------------- > > Key: WFLY-1247 > URL: https://issues.jboss.org/browse/WFLY-1247 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Stuart Douglas > Fix For: 10.0.0.Beta1 > > > We need to define a clear contract between these networking services and the services that use them in order to be able to perform a graceful shutdown of remote connectors. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4964) java.lang.IllegalStateException: channel is closed when using JGroups for HA replication

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4964?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4964. ---------------------------- > java.lang.IllegalStateException: channel is closed when using JGroups for HA replication > ---------------------------------------------------------------------------------------- > > Key: WFLY-4964 > URL: https://issues.jboss.org/browse/WFLY-4964 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Alpha5 > Reporter: Ondřej Kalman > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR1 > > > I'm getting this exception when I try to use <replication-master> and JGroups for cluster discovery: > AMQ222116: unable to start broadcast group bg-group1: java.lang.IllegalStateException: channel is closed > at org.jgroups.JChannel.checkClosed(JChannel.java:959) [jgroups-3.6.3.Final.jar:3.6.3.Final] > at org.jgroups.JChannel._preConnect(JChannel.java:548) [jgroups-3.6.3.Final.jar:3.6.3.Final] > at org.jgroups.JChannel.connect(JChannel.java:288) [jgroups-3.6.3.Final.jar:3.6.3.Final] > at org.jgroups.JChannel.connect(JChannel.java:279) [jgroups-3.6.3.Final.jar:3.6.3.Final] > at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint$JChannelWrapper.connect(JGroupsBroadcastEndpoint.java:211) [artemis-core-client-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:115) [artemis-core-client-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openBroadcaster(JGroupsBroadcastEndpoint.java:101) [artemis-core-client-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.cluster.impl.BroadcastGroupImpl.start(BroadcastGroupImpl.java:105) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.cluster.ClusterManager.start(ClusterManager.java:288) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1904) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:104) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:416) [artemis-server-1.0.0.jar:1.0.0] > at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:414) [artemis-jms-server-1.0.0.jar:1.0.0] > at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:173) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1] > at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:60) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1] > at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:94) [wildfly-messaging-activemq-10.0.0.Alpha4-redhat-1.jar:10.0.0.Alpha4-redhat-1] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_05] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.0.Final.jar:2.2.0.Final] > This issue seems to be the same as: https://issues.apache.org/jira/browse/ARTEMIS-103 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4797) Adjustments for ordered-child-resources

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4797?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4797. ---------------------------- > Adjustments for ordered-child-resources > --------------------------------------- > > Key: WFLY-4797 > URL: https://issues.jboss.org/browse/WFLY-4797 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 10.0.0.Alpha5 > > > https://github.com/wildfly/wildfly-core/pull/813 for WFCORE-759 deprecates some methods, which need to be removed once PR 813 has been merged and released. These changes will come in a future core release, but first we need to update the usage in Full (currently only in JGroups). > Also, the @Override should be uncommented for https://github.com/wildfly/wildfly/pull/7611/files -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4529) Port jboss-as-ee_1_2.xsd to WildFly

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4529?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4529. ---------------------------- > Port jboss-as-ee_1_2.xsd to WildFly > ----------------------------------- > > Key: WFLY-4529 > URL: https://issues.jboss.org/browse/WFLY-4529 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: Darran Lofthouse > Assignee: Richard Opalka > Fix For: 9.0.0.CR2, 10.0.0.Alpha3 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3564) Remove support for mixed-domain transforming to < 7.3.0 versions

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3564?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-3564. ---------------------------- > Remove support for mixed-domain transforming to < 7.3.0 versions > ---------------------------------------------------------------- > > Key: WFLY-3564 > URL: https://issues.jboss.org/browse/WFLY-3564 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 9.0.0.Final, 10.0.0.Alpha4 > > > (Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.) > We will not support WF 9 mixed domains with slaves running releases prior to 7.3 / EAP 6.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running. > KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 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 December 2017