August 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5221) TimerServiceTimerService.getTimers() returns not only the associated timer entries for the current Bean

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5221?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-5221: -------------------------------------- TimerServiceImpl.waitingOnTxCompletionKey should not be static. This resulted in all timers that were created in the current transaction being returned from getAllTimers(). My example above used a single TX per call, which is why it could not reproduce it. > TimerServiceTimerService.getTimers() returns not only the associated timer entries for the current Bean > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-5221 > URL: https://issues.jboss.org/browse/WFLY-5221 > Project: WildFly > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Blocker > > According to the spec [1] the getTimers() method must only return timers associated to the current EJB. > This is a huge issue if timers are cancled by this collection as it will remove all timers! > [1] https://docs.oracle.com/javaee/6/api/javax/ejb/TimerService.html#getTimer... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5221) TimerServiceTimerService.getTimers() returns not only the associated timer entries for the current Bean

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5221?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-5221: -------------------------------------- I attempted to reproduce this here, but it appears to work as expected: https://github.com/wildfly/wildfly/compare/master...stuartwdouglas:WFLY-5221 > TimerServiceTimerService.getTimers() returns not only the associated timer entries for the current Bean > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-5221 > URL: https://issues.jboss.org/browse/WFLY-5221 > Project: WildFly > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Blocker > > According to the spec [1] the getTimers() method must only return timers associated to the current EJB. > This is a huge issue if timers are cancled by this collection as it will remove all timers! > [1] https://docs.oracle.com/javaee/6/api/javax/ejb/TimerService.html#getTimer... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo

by Nick Sawadsky (JIRA)

[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ] Nick Sawadsky commented on JGRP-1954: ------------------------------------- That seems like a reasonable approach as well. My organization can't take on ownership of the protocol at this time, but if someone can split out the protocol into its own project, I can provide the fix. > SWIFT_PING discovery protocol fatal error on OpenStack Kilo > ----------------------------------------------------------- > > Key: JGRP-1954 > URL: https://issues.jboss.org/browse/JGRP-1954 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Environment: JGroups client running on Mac OS X - Yosemite > JDK 1.7.71 > OpenStack Kilo > Reporter: Nick Sawadsky > Assignee: Bela Ban > Fix For: 3.6.5 > > > I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below. > The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java). > I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header". > It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue. > Stack Trace: > 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications > org.xml.sax.SAXParseException: Content is not allowed in prolog. > at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25] > at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25] > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25] > at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-922) Remove unneeded cloning of model nodes when persisting the kernel configs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-922?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-922: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1257692 Bugzilla Update: Perform > Remove unneeded cloning of model nodes when persisting the kernel configs > ------------------------------------------------------------------------- > > Key: WFCORE-922 > URL: https://issues.jboss.org/browse/WFCORE-922 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.Beta4 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.Beta5 > > > In the kernel part of domain.xml, host.xml and standalone.xml marshaling look to eliminate use of ModelNode.asPropertyList(), at least from spots where the ModelNode may be a large data structure. The asPropertyList() call results in a potentially expensive clone of data. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-921) Remove n2 model node cloning in ServerOperationResolver

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-921?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-921: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1257692 Bugzilla Update: Perform > Remove n2 model node cloning in ServerOperationResolver > ------------------------------------------------------- > > Key: WFCORE-921 > URL: https://issues.jboss.org/browse/WFCORE-921 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.Beta4 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.Beta5 > > > ServerOperationResolver gets called for each operation in a composite. > For each call it clones the configuration model. > It then calls node.asPropertyList() in various spots, which in turn results in a clone of the value of each Property. In particular it does this over the profiles, which means each profile gets cloned. > For very large configurations, this is extremely inefficient. One user was experimenting with adding 1000s of data sources and found it would take over an hour to complete the work. I was able to do it in 30 seconds by correcting these problems. > There are other areas where we may be incurring unneeded expense via calls to node.asPropertyList(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-880) Return a success response but the rule seems to be not running.

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-880?page=com.atlassian.jira.plugin... ] Edson Tirelli commented on DROOLS-880: -------------------------------------- I believe the problem is that in your environment, the kie-server is not properly connecting to the the kie-workbench. Can you please show me the result of running a GET on the kie-server containers, like this: GET http://localhost:8230/kie-server-6.3.0-SNAPSHOT-ee7/services/rest/server/... For me, it shows something like this: <response type="SUCCESS" msg="List of created containers"> <kie-containers> <kie-container container-id="kc1" status="STARTED"> <release-id> <artifact-id>kie-server-test</artifact-id> <group-id>org.drools</group-id> <version>1.0.2</version> </release-id> <resolved-release-id> <artifact-id>kie-server-test</artifact-id> <group-id>org.drools</group-id> <version>1.0.2</version> </resolved-release-id> </kie-container> </kie-containers> </response> > Return a success response but the rule seems to be not running. > --------------------------------------------------------------- > > Key: DROOLS-880 > URL: https://issues.jboss.org/browse/DROOLS-880 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.3.0.CR1 > Environment: CPU : Intel(R) Xeon(R) CPU E5-2650 > RAM : 128Gb > Linux Kernel : 2.6.32-431.el6.x86_64 > Drools : 6.3.0.CR1 > Rest Client : Soap UI > Reporter: 재우 이 > Assignee: Mario Fusco > Attachments: 2015_08_20_11_27_43_987.mp4, window-1.1.4.jar > > > Kie_server returns a success rest response status code, but nothing show up in my log file. > It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final") -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-924) Factor out common code for management interface definitions.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-924?page=com.atlassian.jira.plugin... ] Darran Lofthouse edited comment on WFCORE-924 at 8/27/15 4:26 PM: ------------------------------------------------------------------ The class 'org.jboss.as.domain.controller.LocalHostControllerInfo' has probably been overly abused - whilst some information may be required from this interface it has ended up becoming a general purpose container of information used to initialise a management interface. The following are all really items that could be pulled out: - {code} /** * Gets the name of the security realm to use for for native management requests. * * @return the logical interface name */ String getNativeManagementSecurityRealm(); /** * Gets the name of the security realm to use for for HTTP management requests. * * @return the logical interface name */ String getHttpManagementSecurityRealm(); Collection<String> getAllowedOrigins(); {code} Essentially anything that is only used to start up the management interface but does not have another use elsewhere should be removed. was (Author: dlofthouse): The class 'org.jboss.as.domain.controller.LocalHostControllerInfo' has probably been overly abused - whilst some information may be required from this interface it has ended up becoming a general purpose container of information used to initialise a management interface. The following are all really items that could be pulled out: - {code} /** * Gets the name of the security realm to use for for native management requests. * * @return the logical interface name */ String getNativeManagementSecurityRealm(); /** * Gets the name of the security realm to use for for HTTP management requests. * * @return the logical interface name */ String getHttpManagementSecurityRealm(); /** * Gets the username to use when authenticating against the * remote domain controller. * * @return the user name. */ String getRemoteDomainControllerUsername(); Collection<String> getAllowedOrigins(); {code} Essentially anything that is only used to start up the management interface but does not have another use elsewhere should be removed. > Factor out common code for management interface definitions. > ------------------------------------------------------------ > > Key: WFCORE-924 > URL: https://issues.jboss.org/browse/WFCORE-924 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha1 > > > These interfaces started off very simple and initially their attributes were fairly distinct due to the running mode they operated in - however as more and more attributes are added there is more common code than unique code and this is tending to mean all changes are being made in duplicate - double that if a change also impacts on the native definition. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-924) Factor out common code for management interface definitions.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-924?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFCORE-924: ----------------------------------------- The class 'org.jboss.as.domain.controller.LocalHostControllerInfo' has probably been overly abused - whilst some information may be required from this interface it has ended up becoming a general purpose container of information used to initialise a management interface. The following are all really items that could be pulled out: - {code} /** * Gets the name of the security realm to use for for native management requests. * * @return the logical interface name */ String getNativeManagementSecurityRealm(); /** * Gets the name of the security realm to use for for HTTP management requests. * * @return the logical interface name */ String getHttpManagementSecurityRealm(); /** * Gets the username to use when authenticating against the * remote domain controller. * * @return the user name. */ String getRemoteDomainControllerUsername(); Collection<String> getAllowedOrigins(); {code} Essentially anything that is only used to start up the management interface but does not have another use elsewhere should be removed. > Factor out common code for management interface definitions. > ------------------------------------------------------------ > > Key: WFCORE-924 > URL: https://issues.jboss.org/browse/WFCORE-924 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha1 > > > These interfaces started off very simple and initially their attributes were fairly distinct due to the running mode they operated in - however as more and more attributes are added there is more common code than unique code and this is tending to mean all changes are being made in duplicate - double that if a change also impacts on the native definition. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-927) Upgrade sql-api from 2.0.0.Beta1 to 2.0.0.Final

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-927?page=com.atlassian.jira.plugin... ] Tomaz Cerar reassigned WFCORE-927: ---------------------------------- Assignee: Tomaz Cerar (was: Jason Greene) > Upgrade sql-api from 2.0.0.Beta1 to 2.0.0.Final > ----------------------------------------------- > > Key: WFCORE-927 > URL: https://issues.jboss.org/browse/WFCORE-927 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Affects Versions: 2.0.0.Beta4 > Reporter: Fernando Nasser > Assignee: Tomaz Cerar > > We have <version.org.jboss.spec.javax.sql.jboss-javax-sql-api_7.0_spec>2.0.0.Beta1 when there is a 2.0.0.Final already. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-927) Upgrade sql-api from 2.0.0.Beta1 to 2.0.0.Final

by Fernando Nasser (JIRA)

Fernando Nasser created WFCORE-927: -------------------------------------- Summary: Upgrade sql-api from 2.0.0.Beta1 to 2.0.0.Final Key: WFCORE-927 URL: https://issues.jboss.org/browse/WFCORE-927 Project: WildFly Core Issue Type: Component Upgrade Components: Server Affects Versions: 2.0.0.Beta4 Reporter: Fernando Nasser Assignee: Jason Greene We have <version.org.jboss.spec.javax.sql.jboss-javax-sql-api_7.0_spec>2.0.0.Beta1 when there is a 2.0.0.Final already. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2015