January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Deleted: (JBAS-4652) Upgrade Hibernate Annotations to 3.3.1 (from 3.3.0)

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-4652?page=all ] Dimitris Andreadis deleted JBAS-4652: ------------------------------------- > Upgrade Hibernate Annotations to 3.3.1 (from 3.3.0) > --------------------------------------------------- > > Key: JBAS-4652 > URL: http://jira.jboss.com/jira/browse/JBAS-4652 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Dimitris Andreadis > -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5106) jar file inside a jar file inside an ear file is developed as not in the ear

by David Cervigni (JIRA)

jar file inside a jar file inside an ear file is developed as not in the ear ---------------------------------------------------------------------------- Key: JBAS-5106 URL: http://jira.jboss.com/jira/browse/JBAS-5106 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA Environment: windows, jrockit Reporter: David Cervigni esb3 sessions beans inside a jar inside a jar (it was an error in my case but it was so) inside the main ear was deployed without the "ear name" prefix the archive was: ear file ------>module.jar -------->nested.jar file the nested jar was deployed as it was outside the ear -- 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

18 years, 4 months

2
2
0 / 0

[JBoss JIRA] Closed: (GPD-194) CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-194?page=all ] Koen Aers closed GPD-194. ------------------------- Resolution: Done > CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD > -------------------------------------------------------------- > > Key: GPD-194 > URL: http://jira.jboss.com/jira/browse/GPD-194 > Project: JBoss jBPM GPD > Issue Type: Bug > Affects Versions: jBPM jPDL Designer 3.1.1 > Environment: JBoss Developer Studio, Build id: 200712091205-nightly > and > Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > Reporter: Koen Aers > Assigned To: Koen Aers > Fix For: jBPM jPDL Designer 3.2.0.alpha1, jBPM jPDL Designer 3.1.2 > > > I'm unable to generate a new form for a task with either the 1.0 JBDS bits or Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > To recreate the problem - using the attached jBPM process project - it's based on the 'holiday request' jBPM demo - at the start task node, attempt to generate a form. > The screen displayed in the screenshot attachment is brought up - pressing OK has no effect. The form xhtml file is not created - and no error/sttaus message is displayed. > -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (GPD-194) CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-194?page=all ] Koen Aers updated GPD-194: -------------------------- Fix Version/s: jBPM jPDL Designer 3.2.0.alpha1 jBPM jPDL Designer 3.1.2 > CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD > -------------------------------------------------------------- > > Key: GPD-194 > URL: http://jira.jboss.com/jira/browse/GPD-194 > Project: JBoss jBPM GPD > Issue Type: Bug > Affects Versions: jBPM jPDL Designer 3.1.1 > Environment: JBoss Developer Studio, Build id: 200712091205-nightly > and > Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > Reporter: Koen Aers > Assigned To: Koen Aers > Fix For: jBPM jPDL Designer 3.2.0.alpha1, jBPM jPDL Designer 3.1.2 > > > I'm unable to generate a new form for a task with either the 1.0 JBDS bits or Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > To recreate the problem - using the attached jBPM process project - it's based on the 'holiday request' jBPM demo - at the start task node, attempt to generate a form. > The screen displayed in the screenshot attachment is brought up - pressing OK has no effect. The form xhtml file is not created - and no error/sttaus message is displayed. > -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Moved: (GPD-194) CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-194?page=all ] Koen Aers moved JBIDE-1589 to GPD-194: -------------------------------------- Project: JBoss jBPM GPD (was: Tools (JBoss Tools)) Key: GPD-194 (was: JBIDE-1589) Affects Version/s: jBPM jPDL Designer 3.1.1 (was: 2.0.0.GA) > CLONE -JBDS - cannot generate a form for a task via (jBPM) GPD > -------------------------------------------------------------- > > Key: GPD-194 > URL: http://jira.jboss.com/jira/browse/GPD-194 > Project: JBoss jBPM GPD > Issue Type: Bug > Affects Versions: jBPM jPDL Designer 3.1.1 > Environment: JBoss Developer Studio, Build id: 200712091205-nightly > and > Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > Reporter: Koen Aers > Assigned To: Koen Aers > Fix For: jBPM jPDL Designer 3.2.0.alpha1, jBPM jPDL Designer 3.1.2 > > > I'm unable to generate a new form for a task with either the 1.0 JBDS bits or Eclipse Europa + jbpm-jpdl-designer-3.0.13 Stable 9.2 MB 2007-01-25 > To recreate the problem - using the attached jBPM process project - it's based on the 'holiday request' jBPM demo - at the start task node, attempt to generate a form. > The screen displayed in the screenshot attachment is brought up - pressing OK has no effect. The form xhtml file is not created - and no error/sttaus message is displayed. > -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-2235) Server Controller Tasks: Throw error if normal shutdown fails

by Martin Vecera (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2235?page=all ] Martin Vecera reassigned JBAS-2235: ----------------------------------- Assignee: (was: Martin Vecera) > Server Controller Tasks: Throw error if normal shutdown fails > ------------------------------------------------------------- > > Key: JBAS-2235 > URL: http://jira.jboss.com/jira/browse/JBAS-2235 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite > Environment: jboss-4.0 tip > Reporter: Ryan Campbell > Fix For: JBossAS-5.0.0.Beta4 > > Attachments: jboss-test-diff > > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > Currently, when a server fails to respond to a shutdown request, the process is killed and the tests continue. > There should be an error thrown if the server fails to shutdown within the timeout period. -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2647) Remove potential deadlock condition from HASingletonSupport

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2647?page=comments#action_12393951 ] Dimitris Andreadis commented on JBAS-2647: ------------------------------------------ Brian, can you please update this dated task (and the parent task)? > Remove potential deadlock condition from HASingletonSupport > ----------------------------------------------------------- > > Key: JBAS-2647 > URL: http://jira.jboss.com/jira/browse/JBAS-2647 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.0.Beta4 > > > The startService() implementation HASingletonSupport inherits from HAServiceMBeanSupport has a slight potential for deadlock is a cluster topology change occurs while the singleton service itself is being deployed. The only known use case where this would occur is with the HASingletonDeployer service. > Details: > In Thread A > 1) HASingletonDeployerServices is being deployed, and therefore has synchronized on org.jboss.system.ServiceController. > 2) Calls DRM.registerListener() > 3) Call DRM.add() (this is the next line of code) > 4) As part of add processing, DRM callsback to the HASingleton. > 5) Inside a synchronized block in the callback method, singleton determines if it is the master node, goes on to do its work. > Problem occurs if a cluster topology change occurs between steps 2 and 3. In that case, the following would happen in another thread, Thread B. > 1) Topology changes, so DRM notifies listeners. > 2) Our HASingleton is registered as a listener, so step 5 above occurs. > 3) Since its the master, goes and tries to deploy things in deploy-hasingleton. > 4) Deployment can't proceed because Thread A has synchronized on org.jboss.system.ServiceController. > 5) Thread A can't proceed because Thread B is stuck inside the synchronized block in the callback method. Deadlock. > This is an unlikely scenario, but I'm marking this issue as major since if it does occur it deadlocks the node. > A likely fix will involve overriding the startService() implemetation so it doesn't rely on the callback to determine whether or not its the master node. Instead it directly does what the callback code does, and then registers as a listener. Have to be careful not to drop any topology changes in the middle. -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-1407) Analytics to use Janino compiler

by Michael Neale (JIRA)

Analytics to use Janino compiler -------------------------------- Key: JBRULES-1407 URL: http://jira.jboss.com/jira/browse/JBRULES-1407 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.5 Reporter: Michael Neale Assigned To: Michael Neale Fix For: 4.1.0 -- 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

18 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1257) Create notification for buddy group change event

by Manik Surtani (JIRA)

Create notification for buddy group change event ------------------------------------------------ Key: JBCACHE-1257 URL: http://jira.jboss.com/jira/browse/JBCACHE-1257 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Buddy Replication Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.CR3, 2.1.0.GA -- 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

18 years, 4 months

1
1
0 / 0

[JBoss JIRA] Commented: (JGRP-129) Logical addresses

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-129?page=comments#action_12393932 ] Bela Ban commented on JGRP-129: ------------------------------- Optimization: we could shorts which are indicex into a hashmap of logical addresses (which in turn map to physical addresses), and only send around the shorts. Need to make sure those are unique across the cluster though, probably via a short voting/election phase on startup in TP... > Logical addresses > ----------------- > > Key: JGRP-129 > URL: http://jira.jboss.com/jira/browse/JGRP-129 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.x > > > The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough: > - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper > - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC > - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on > - Network Address Translation: the sender's address might get changed by the NAT > DESIGN: > - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called. > - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true"). > - The logical addresses must be picked such that they cannot be reused after disconnect()/close(). -- 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

18 years, 4 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 January 2008