March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMETA-263) Add support for processing concurrency management annotation and its xml equivalent

by jaikiran pai (JIRA)

Add support for processing concurrency management annotation and its xml equivalent ----------------------------------------------------------------------------------- Key: JBMETA-263 URL: https://jira.jboss.org/jira/browse/JBMETA-263 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Components: ejb Reporter: jaikiran pai Assignee: jaikiran pai Add support for processing @ConcurrencyManagement and its xml equivalent -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-224) Genericize ReplicantsManagerInterceptor

by Brian Stansberry (JIRA)

Genericize ReplicantsManagerInterceptor --------------------------------------- Key: JBCLUSTER-224 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-224 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-API Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: HA-Server-API 2.0.0.Beta1 Changes the constructor, so can only be done in a major release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7216) upgrade to the latest 2.x.x metadata

by Alexey Loubyansky (JIRA)

upgrade to the latest 2.x.x metadata ------------------------------------ Key: JBAS-7216 URL: https://jira.jboss.org/jira/browse/JBAS-7216 Project: JBoss Application Server Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: JBossAS-6.0.0.Alpha1 In 2.x.x metadata got split into subprojects http://www.jboss.org/community/wiki/JBossMetaData. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-6941) consistency between XSD, propOrder and XML in the MC

by Alexey Loubyansky (JIRA)

consistency between XSD, propOrder and XML in the MC ---------------------------------------------------- Key: JBAS-6941 URL: https://jira.jboss.org/jira/browse/JBAS-6941 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: JBossAS-5.1.1.GA E.g. currently in SVN for beanType <xsd:complexType name="beanType"> <xsd:sequence> <xsd:element name="alias" type="aliasType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="related-class" type="relatedClassType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="annotation" type="annotationType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="classloader" type="classloaderType" minOccurs="0"/> <xsd:element name="constructor" type="constructorType" minOccurs="0"/> <xsd:element name="property" type="propertyType" minOccurs="0" maxOccurs="unbounded"/> ... @XmlType(name="beanType", propOrder={"aliasMetaData", "related", "annotations", "classLoader", "constructor", "properties", "create", "start", "stop", "destroy", "depends", "demands", "supplies", "installs", "uninstalls", "installCallbacks", "uninstallCallbacks"}) public class AbstractBeanMetaData extends AbstractFeatureMetaData ... vfs.xml <bean name="VFSCache"> <constructor factoryClass="org.jboss.virtual.spi.cache.VFSCacheFactory" factoryMethod="getInstance">  <parameter>org.jboss.virtual.plugins.cache.CombinedVFSCache</parameter> </constructor> <start ignored="true"/> <property name="permanentRoots"> ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1042) Provide better reporting of ChannelExceptions when debugging

by Richard Achmatowicz (JIRA)

Provide better reporting of ChannelExceptions when debugging ------------------------------------------------------------ Key: JGRP-1042 URL: https://jira.jboss.org/jira/browse/JGRP-1042 Project: JGroups Issue Type: Feature Request Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz Priority: Minor I spent a lot of time recently trying to track down some testsuite failures, where tests were failing with: "failed to start protocol stack" org.jgroups.ChannelException at org.jgroups.JChannel.startStack(JChannel.java:1766) at org.jgroups.JChannel.connect(JChannel.java:407) at org.jgroups.JChannel.connect(JChannel.java:382) at org.jgroups.tests.ChannelTest.testBasicOperations(ChannelTest.java:27) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580) at org.testng.internal.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:49) at org.testng.internal.InvokeMethodRunnable.run(InvokeMethodRunnable.java:40) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Turning on DEBUG level logging didn't help. I finally tracked the error down to an UnknownHostException which was getting raised in UDP.createSockets() during a call to InetAddress.getByname(). This checked exception was then passing through the following methods: UDP.createSockets() throws Exception ; UDP.start() throws Exception ; ProtocolStack.startStack() throws Exception ; JChannel.startStack() throws ChannelException ; There are a lot of potential exceptions which can occur when starting a stack, and these are getting masked to a large extent. It makes debugging stack startup problems painful, as the only way to get more information about the problem is to write code to unpack the ChannelException and print out its cause. I'd like to add some simple logging statements to the exception handler in JChannel.startStack() to make debugging the startup of stacks easier. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-1156) Recreate socket on NoRouteToHost exception

by Bela Ban (JIRA)

Recreate socket on NoRouteToHost exception ------------------------------------------ Key: JGRP-1156 URL: https://jira.jboss.org/jira/browse/JGRP-1156 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 I've got a customer [1] that started receiving the following error during multicast sends (from MERGE in this particular log) until JBoss was restarted: [Email Dennis] [org.jgroups.protocols.UDP] [ERROR] failed sending message to null (0 bytes) java.net.NoRouteToHostException: No route to host: Datagram send failed I've had one other case with this symptom. In that case, they had bonded network interfaces and were testing failover by bringing one side of it down. It looks to me like something is screwed up at the OS level that doesn't get fixed until JBoss is restarted (or the socket is recreated?). Is there anything we could do about this at the JGroups level? The customer has asked why we don't recreate the socket when this exception happens. But that doesn't seem like a good solution to me since there's nothing about a NoRouteToHostException that should indicate the socket needs recreated. -Dennis [End email Dennis] One thing we could investigate is to close and recreate a socket when such an exception is encountered. Possibly other exceptions as well... This would affect the transports (UDP and TCP), plus some of the protocols which use sockets, e.g. MPING, FD_SOCK, STREAMING_STATE_TRANSFER etc... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-1177) Multiple components using the same channel

by Bela Ban (JIRA)

Multiple components using the same channel ------------------------------------------ Key: JGRP-1177 URL: https://jira.jboss.org/jira/browse/JGRP-1177 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 Investigate sharing a channel between multiple components. Unlike the Multiplexer, this is light weight and doesn't require service views or other kludges ! Attached is an example of how this could be implemented. This JIRA is only to investigate whether being able to share a channel between multiple components makes sense, or whether a shared transport is better suited. We do NOT want to re-create the Multiplexer, which to this day still haunts me ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JBRULES-2465) Corruption of Rete when removing complex NotNodes

by Andreas Kohn (JIRA)

Corruption of Rete when removing complex NotNodes ------------------------------------------------- Key: JBRULES-2465 URL: https://jira.jboss.org/jira/browse/JBRULES-2465 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Reporter: Andreas Kohn Assignee: Mark Proctor Attachments: drools-core-betanode-remove.diff while working further on our drools integration we came across an odd exception when removing a particular rule: java.lang.IllegalArgumentException: Cannot remove a sink, when the list of sinks is null at org.drools.reteoo.ObjectSource.removeObjectSink(ObjectSource.java:159) at org.drools.reteoo.RightInputAdapterNode.doRemove(RightInputAdapterNode.java:217) at org.drools.common.BaseNode.remove(BaseNode.java:95) at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:275) at org.drools.common.BaseNode.remove(BaseNode.java:95) at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:280) at org.drools.common.BaseNode.remove(BaseNode.java:95) at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:387) at org.drools.common.BaseNode.remove(BaseNode.java:95) at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:237) at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:371) at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:746) While stepping through the code it looked like the network was corrupt (there was indeed no sinks on the ObjectSource, but the node calling removeObjectSink was still linked to it and claiming it as source). The rule itself contains multiple NotNodes, checking a condition that looks like this: not(not(Foo.v = X) and not(Foo.v = Y)) I could track this down to some sort of "loop" in the rete that triggers this when the outer not node is removed. When removing BetaNode#doRemove() first walks along 'rightInput': this.rightInput.remove( context, builder, this, workingMemories ); and eventually _in that call_ it also hits a node that is the direct 'leftInput' of the original beta node. The removal marks that node as visited in the removal context, and when the 'rightInput.remove' returns to the beta node it does not visit the leftInput due to this condition in BetaNode#doRemove(): if ( !context.alreadyVisited( this.leftInput ) ) { this.leftInput.remove( context, builder, this, workingMemories ); } In other words: before the remove the BetaNode had another node that was both referenced directly as 'leftInput', as well as an input to the 'rightInput'. The first removal of the rule "worked", and no exceptions happened. But: any further attempt to re-add the same rule and remove it again lead to the exception above. I was able to fix it with the attached patch, reproduced here: + boolean needRemoveFromLeft = !context.alreadyVisited( this.leftInput ); this.rightInput.remove( context, builder, this, workingMemories ); - if ( !context.alreadyVisited( this.leftInput ) ) { + if ( needRemoveFromLeft ) { this.leftInput.remove( context, builder, this, workingMemories ); } With this patch applied I could add/delete/add the particular rule repeatedly without problems. The attached patch also adds an assert in ObjectSource#removeObjectSink(): when removing a sink from an object source with only one sink the sink was unconditionally replaced with an empty sink, although the argument ObjectSink could be a different sink than the one in the ObjectSource. For CompositeObjectSinkAdapters this case is checked, but not for single sinks. I originally suspected that place to be responsible for the problem I observed but the assertion never fired in my tests. (taken from rules-dev mail "Bug in BetaNode#doRemove()?" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
11
0 / 0

[JBoss JIRA] Created: (JBAS-7676) ejbClass is null in JBossEnterpriseBeanMetaData

by Pete Muir (JIRA)

ejbClass is null in JBossEnterpriseBeanMetaData ----------------------------------------------- Key: JBAS-7676 URL: https://jira.jboss.org/jira/browse/JBAS-7676 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Environment: r100034 Reporter: Pete Muir Assignee: Carlo de Wolf Fix For: JBossAS-6.0.0.M2 When deploy the classes in http://anonsvn.jboss.org/repos/weld/cdi-tck/tags/1.0.1-CR1/impl/src/main/... as an EAR with all classes placed in the ejb-jar (see attached for archive), the JBossEnterpiseBeanMetaData is giving a null for the BorderCollie SLSB (it didn't do this on 6.0 M1 or 5.1). To reproduce, just put the EAR into the deploy dir. To debug, you will need the sources for weld-jboss-int - http://anonsvn.jboss.org/repos/jbossas/projects/weld-int/trunk/ - and you can break inside the constructor for JBossEJBDescriptorAdaptor. For now I will disable the test in CDI TCK with this issue as the reason -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
11
0 / 0

[JBoss JIRA] Created: (JBAS-7845) Upgrade jboss-ejb-api_3.1_spec to 1.0.0.Beta2

by jaikiran pai (JIRA)

Upgrade jboss-ejb-api_3.1_spec to 1.0.0.Beta2 --------------------------------------------- Key: JBAS-7845 URL: https://jira.jboss.org/jira/browse/JBAS-7845 Project: JBoss Application Server Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: EJB3 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: JBossAS-6.0.0.M3 Upgrade to the recently released 1.0.0.Beta2 of org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
2
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 March 2010