July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3580) EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection

by Derek Horton (JIRA)

Derek Horton created WFLY-3580: ---------------------------------- Summary: EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection Key: WFLY-3580 URL: https://issues.jboss.org/browse/WFLY-3580 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management, EJB Reporter: Derek Horton Assignee: Darran Lofthouse EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-538) Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring

by Maruthi Shanmugam (JIRA)

[ https://issues.jboss.org/browse/DROOLS-538?page=com.atlassian.jira.plugin... ] Maruthi Shanmugam commented on DROOLS-538: ------------------------------------------ Hi David, Also do we have any similiar issue in Drools 4.0.4, because I see those packages doesnt use ClassFieldAccessorCache. Your quick response is much appreciated. > Unable to resolve class error , drools 5.5 in concurrent execution. JSR94Support and Spring > -------------------------------------------------------------------------------------------- > > Key: DROOLS-538 > URL: https://issues.jboss.org/browse/DROOLS-538 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Environment: Linux Red Hat , Enterprise, JDK 1.6, Drools 5.5.Final > Reporter: Maruthi Shanmugam > Assignee: Mark Proctor > Priority: Blocker > > We use Drools 5.5 and drool implementation is done through Spring JSR94Support API> > The Rule engine is called in concurrent mode, > i.e , JSR94Support.executeStateless(name,list) is executed through multiple threads. > And when the rules are executed we randomly get the following exception > org.drools.RuntimeDroolsException: Unable to resolve class 'someclass(this is sample)here actual class is printed>' > at org.drools.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:126) > at org.drools.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:48) > at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:83) > at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71) > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:159) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847) > at org.drools.reteoo.ReteooStatelessSession.executeWithResults(ReteooStatelessSession.java:273) > The rules are registered every 15 minutes through RuleAdministrator.registerRuleExecutionset , > so whenever we refresh the rules and the subsequent thread even after the registration is completed, fails with the above message. This happens only when the rules are invoked concurrently. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1859) Allow Configurator to load protocols from a specific classloader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1859?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1859. ---------------------------- Resolution: Done > Allow Configurator to load protocols from a specific classloader > ---------------------------------------------------------------- > > Key: JGRP-1859 > URL: https://issues.jboss.org/browse/JGRP-1859 > Project: JGroups > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 3.4.4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 3.5 > > > To support custom protocols in WildFly, we need to allow the users to define the module from which to load a given protocol class. WildFly currently uses the Configurator to create its protocol stack. Currently, the classloader used to load protocol classes is hard coded to the classloader that loaded the Stack class. This should be configurable via org.jgroups.conf.ProtocolConfiguration. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3575) Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-3575?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-3575: ------------------------------------------- https://issues.jboss.org/browse/WFLY-1357?filter=12313624 I think Rado's approach of ignoring works pretty well. > Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet > ------------------------------------------------------------------------- > > Key: WFLY-3575 > URL: https://issues.jboss.org/browse/WFLY-3575 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > I wasted a good couple of hours today trying to figure out why my changes broke the xsite tests. It turns out that the xslt scripts have the subsystem schema version hardcoded, and I had created a new schema version. > We should parameterize this, in the same way as the addCacheContainer.xsl stylesheet does. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2729) Improve reporting when persistent session restore fails

by Ariel Küchler (JIRA)

[ https://issues.jboss.org/browse/WFLY-2729?page=com.atlassian.jira.plugin.... ] Ariel Küchler commented on WFLY-2729: ------------------------------------- See this issue: JBMAR-163 > Improve reporting when persistent session restore fails > ------------------------------------------------------- > > Key: WFLY-2729 > URL: https://issues.jboss.org/browse/WFLY-2729 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.CR1 > Environment: Ubuntu Linux > Reporter: Paa Kojo Konduah Amos > Assignee: Tomaz Cerar > Fix For: 9.0.0.CR1 > > Attachments: BdfHJ0fCUAAdRW5.png > > > when you right clean on Server to clean it. it throws an Error -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on WFLY-3189: ------------------------------------------- besides the missing files there does seem to be a problem in Eclipse XML validation when it comes to using types from xs:import - i've (re)opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=315741 to track down that part. > Error validating jboss-ejb3.xml. > -------------------------------- > > Key: WFLY-3189 > URL: https://issues.jboss.org/browse/WFLY-3189 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > > I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error: > {noformat} > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33] > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37] > src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39] > {noformat} > The jboss-ejb3.xml is quite simple: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <jboss:ejb-jar version="3.1" impl-version="2.0" > xmlns="http://java.sun.com/xml/ns/javaee" > xmlns:jboss="http://www.jboss.com/xml/ns/javaee" > xmlns:s="urn:security:1.1" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd > http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd"> > <assembly-descriptor> > <s:security> > <ejb-name>*</ejb-name> > <s:security-domain>testsd</s:security-domain> > </s:security> > </assembly-descriptor> > </jboss:ejb-jar> > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3359) Transferring an operation attachments to slaves may lead to an OOM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3359?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3359: ----------------------------------------------- Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1108952|https://bugzilla.redhat.com/show_bug.cgi?id=1108952] from ON_QA to VERIFIED > Transferring an operation attachments to slaves may lead to an OOM > ------------------------------------------------------------------ > > Key: WFLY-3359 > URL: https://issues.jboss.org/browse/WFLY-3359 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 9.0.0.Alpha1 > > > Transferring an operation attachment to a slave may lead to an OutOfMemoryError. > {code} > 19:44:47,794 ERROR [stderr] (domain-mgmt-handler-thread - 13) Exception in thread "domain-mgmt-handler-thread - 13" java.lang.OutOfMemoryError: Java heap space > 19:44:47,795 ERROR [stderr] (domain-mgmt-handler-thread - 13) at java.util.Arrays.copyOf(Arrays.java:2271) > 19:44:47,795 ERROR [stderr] (domain-mgmt-handler-thread - 13) at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:178) > 19:44:47,795 ERROR [stderr] (domain-mgmt-handler-thread - 13) at org.jboss.as.controller.remote.TransactionalProtocolClientImpl$ReadAttachmentInputStreamRequestHandler$1.execute(TransactionalProtocolClientImpl.java:277) > 19:44:47,796 ERROR [stderr] (domain-mgmt-handler-thread - 13) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) > 19:44:47,796 ERROR [stderr] (domain-mgmt-handler-thread - 13) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) > 19:44:47,797 ERROR [stderr] (domain-mgmt-handler-thread - 13) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > 19:44:47,797 ERROR [stderr] (domain-mgmt-handler-thread - 13) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > 19:44:47,797 ERROR [stderr] (domain-mgmt-handler-thread - 13) at java.lang.Thread.run(Thread.java:724) > 19:44:47,798 ERROR [stderr] (domain-mgmt-handler-thread - 13) at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3575) Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3575?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-3575: --------------------------------- Summary: Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet (was: Parameterize subsystem version in xsite testsuite xslt stylesheet) > Parameterize subsystem version in xsite/jgroups testsuite xslt stylesheet > ------------------------------------------------------------------------- > > Key: WFLY-3575 > URL: https://issues.jboss.org/browse/WFLY-3575 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > I wasted a good couple of hours today trying to figure out why my changes broke the xsite tests. It turns out that the xslt scripts have the subsystem schema version hardcoded, and I had created a new schema version. > We should parameterize this, in the same way as the addCacheContainer.xsl stylesheet does. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1859) Allow Configurator to load protocols from a specific classloader

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-1859?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on JGRP-1859: ------------------------------------ https://github.com/belaban/JGroups/pull/158 > Allow Configurator to load protocols from a specific classloader > ---------------------------------------------------------------- > > Key: JGRP-1859 > URL: https://issues.jboss.org/browse/JGRP-1859 > Project: JGroups > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 3.4.4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 3.5 > > > To support custom protocols in WildFly, we need to allow the users to define the module from which to load a given protocol class. WildFly currently uses the Configurator to create its protocol stack. Currently, the classloader used to load protocol classes is hard coded to the classloader that loaded the Stack class. This should be configurable via org.jgroups.conf.ProtocolConfiguration. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1859) Allow Configurator to load protocols from a specific classloader

by Paul Ferraro (JIRA)

Paul Ferraro created JGRP-1859: ---------------------------------- Summary: Allow Configurator to load protocols from a specific classloader Key: JGRP-1859 URL: https://issues.jboss.org/browse/JGRP-1859 Project: JGroups Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 3.4.4 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 3.5 To support custom protocols in WildFly, we need to allow the users to define the module from which to load a given protocol class. WildFly currently uses the Configurator to create its protocol stack. Currently, the classloader used to load protocol classes is hard coded to the classloader that loaded the Stack class. This should be configurable via org.jgroups.conf.ProtocolConfiguration. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

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 July 2014