March 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMICROCONT-417) GenericBeanAspectFactory.getCreatingClassLoader() should fall back to advisor's classloader

by Kabir Khan (JIRA)

GenericBeanAspectFactory.getCreatingClassLoader() should fall back to advisor's classloader ------------------------------------------------------------------------------------------- Key: JBMICROCONT-417 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-417 Project: JBoss Microcontainer Issue Type: Bug Affects Versions: JBossMC-2.0.4.GA Reporter: Kabir Khan Assignee: Kabir Khan Fix For: JBossMC-2.2.0.Beta1 -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-346) Mavenize Docbook support

by Paul Gier (JIRA)

Mavenize Docbook support ------------------------ Key: JBBUILD-346 URL: http://jira.jboss.com/jira/browse/JBBUILD-346 Project: JBoss Build System Issue Type: Feature Request Components: Maven Reporter: Paul Gier Fix For: MavenBuild 2.0 Migrate docbook-support from ant to maven. https://svn.jboss.org/repos/jbossas/trunk/docbook-support/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-506) Replace the app server module builds with maven build output.

by Paul Gier (JIRA)

Replace the app server module builds with maven build output. ------------------------------------------------------------- Key: JBBUILD-506 URL: https://jira.jboss.org/jira/browse/JBBUILD-506 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: Maven Build - App Server (Phase 2) The app server modules should gradually be transitioned from buildmagic to maven. Each maven module should copy it's current target output to the correct location in the "output" directory. The buildmagic modules should be able to use the output from the maven build. -- 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

15 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-925) TCPPING: not all nodes have all physical addresses

by Bela Ban (JIRA)

TCPPING: not all nodes have all physical addresses -------------------------------------------------- Key: JGRP-925 URL: https://jira.jboss.org/jira/browse/JGRP-925 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 - We have A and B - TCPPING for A and B lists A and B as initial_hosts - C's config lists only A as initial_hosts - When C joins, it 'll ping only A, so it has information about A's physical address in its cache - Plus, the discovery response from A also adds information about A to C's cache - HOWEVER, C does not have the physical address of B, and B doesn't have the physical address of C ! --> When C multicasts a message, B will not receive it --> When B multicasts a message, C will not receive it The reason is that a discovery response from a node N only contains the logical-physical mapping for N, but not for other nodes. SOLUTION: introduce property return_entire_cache. By default, this is false, but TCPPING sets it to true. When A gets the discovery request from C, it'll return information about A *and* B. When B wants to send a multicast, it'll skip C though, but on the next MERGE2, it'll get the physical address of C. Retransmission will then make sure C receives B previously dropped multicast -- 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

15 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-918) Logical addresses: removing a logical name or UUID/PhysicalAddress mapping on a view change is incorrect

by Bela Ban (JIRA)

Logical addresses: removing a logical name or UUID/PhysicalAddress mapping on a view change is incorrect -------------------------------------------------------------------------------------------------------- Key: JGRP-918 URL: https://jira.jboss.org/jira/browse/JGRP-918 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.8 In TP.down(), when receiving a view V, we - remove all mappings for members not in V from logical_addr_cache and - remove all mappings in UUID.cache for members not in V This is incorrect, because #1 We might have multiple channels in the same JVM, and any given view only pertains to a specific channel C1. But if we remove all mappings for members not in C1's view from UUID.cache, which is a JVM singleton, then we remove mappings for C2's view #2 With a shared channel, we share TP's logical_addr_cache among all channels, so we cannot do this either -- 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

15 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (BPEL-304) NullPointerException on ScopeInstance calling process with correlation after restart

by Carlos (JIRA)

NullPointerException on ScopeInstance calling process with correlation after restart ------------------------------------------------------------------------------------ Key: BPEL-304 URL: https://jira.jboss.org/jira/browse/BPEL-304 Project: JBoss jBPM BPEL Issue Type: Bug Security Level: Public (Everyone can see) Components: Engine Affects Versions: jBPM BPEL 1.1.1 Environment: JBoss 4.2.3 + Windows XP and JBoss 4.2.3 para RedHat Linux Reporter: Carlos Assignee: Alejandro Guizar After start a process with correlationIds setted i waited for the process to stop on a receive node, then i stopped jboss normally and started it again. After the restart i called the same process passing the correlationId necessary to continue. Jbpm throwed: NullPointerException on org.jbpm.bpel.graph.exe.ScopeInstance.completed() (line 140) because the property state was null. I checked jbpm_scopeinstance and there is a state on it (AP). I debugged, dit some hqls for this ScopeInstance with hibernate on tab display with Eclipse, and it never gets the state property. So i did the following, on Eclipse during debug i executed the following line on display tab. ScopeState fake = ActiveState.PRIMARY; After that, executed the hql again, then state property was get. I guess it's a classLoading x Hibernate problem. If ater restart, a new process is executed and after that execute one process waiting for a correlation, the state property is found To solve my problem quickyly i did the following on public constructor ScopeInstance ScopeInstance() { ScopeState fake = ActiveState.PRIMARY; fake = CompensatingState.DEFAULT; fake = CompensatingState.DEFAULT; fake = EndState.COMPENSATED; fake = FaultingState.DEFAULT; fake = TerminatingState.DEFAULT; fake = CompensatingState.DEFAULT; } All the state classes need to be loaded. This is not nice =D, i know i could use a loadClass, but anyway its only a workaround =D -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2337) Redirect to JBoss Portal Login page after successfully authenticating with CAS

by Dejan Gambin (JIRA)

Redirect to JBoss Portal Login page after successfully authenticating with CAS ------------------------------------------------------------------------------ Key: JBPORTAL-2337 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2337 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Security Affects Versions: 2.7.1 Final Environment: OS Windows XP SP3, JDK 1.5, JBoss Portal 2.7.1 Bundled Reporter: Dejan Gambin - Enabling SSL on JBoss - Making all the necessayry steps for CAS Server integration according to Reference Guide - Going to Portal page https://localhost:8443/portal - Click on Login - After successfully authenticating on CAS login page I get JBoss portal Login page (I shouldn't, right?) -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBXB-190) MutableSchemaResolver interface

by Alexey Loubyansky (JIRA)

MutableSchemaResolver interface ------------------------------- Key: JBXB-190 URL: https://jira.jboss.org/jira/browse/JBXB-190 Project: JBoss XML Binding (JBossXB) Issue Type: Task Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: JBossXB-2.0.1.CR1 This would be an extension of SchemaBindingResolver with methods to map classes to schema location and/or namespace, schema initializers, etc. Existing resolver implementations DefaultSchemaResolver and MultiClassSchemaResolver should implement MutableSchemaResolver interface. -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-921) TP: 'header' is ambiguous with shared transport

by Bela Ban (JIRA)

TP: 'header' is ambiguous with shared transport ----------------------------------------------- Key: JGRP-921 URL: https://jira.jboss.org/jira/browse/JGRP-921 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.6.9, 2.8 TP.header is created on down(CONNECT). However if we have members A and B on the *same shared transport*, then A.connect("cluster-1") sets TP.header to "cluster-1", but B.connect("cluster-2") sets TP.header to "cluster-2". This means that messages sent by A will get received by B !! Investigate whether this was introduced by logical addresses only, or whether it affects 2.6.x as well ! -- 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

15 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-920) TP: channel_name is ambiguous with shared transport

by Bela Ban (JIRA)

TP: channel_name is ambiguous with shared transport --------------------------------------------------- Key: JGRP-920 URL: https://jira.jboss.org/jira/browse/JGRP-920 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 TP.channel_name should be associated with a channel when using a shared transport -- 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

15 years, 10 months

1
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2009