January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBPM-649) Allow arbitrary process definition name to show in src folders in GPD

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-649?page=all ] Koen Aers closed JBPM-649. -------------------------- Resolution: Done I assume the issue is solved? If it is not the case, please create it anew in the GPD project. > Allow arbitrary process definition name to show in src folders in GPD > --------------------------------------------------------------------- > > Key: JBPM-649 > URL: http://jira.jboss.com/jira/browse/JBPM-649 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Graphical Process Designer > Environment: Windows XP SP2, JBoss IDE 1.5.1 GA Bundle, GPD 3.0.9.1 (and 3.0.9) > Reporter: David Hosier > Assigned To: Tom Baeyens > > Ok, so I've discovered what the deal is with this...and I apologize for making this a mess. If you do not give a new process definition a .par extension in the name, the project treats it as an empty package. If you have the empty packages filter on, the process definition does not show up when the folder is set as a src folder. It would be nice if maybe there was a distinction between the name of the exploded par and the name that gets inserted into the process definition. Or you might automatically add a .par to the folder name and use the name as defined in the source. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-404) Get rid of MessageProtocol

by Bela Ban (JIRA)

Get rid of MessageProtocol -------------------------- Key: JGRP-404 URL: http://jira.jboss.com/jira/browse/JGRP-404 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 3.0 Crap from the old days where protocols were implemented using cluster method calls -- 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

19 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-407) Get rid of RpcProtocol and all subclasses

by Bela Ban (JIRA)

Get rid of RpcProtocol and all subclasses ----------------------------------------- Key: JGRP-407 URL: http://jira.jboss.com/jira/browse/JGRP-407 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Including GMS, FLUSH, TOTAL_TOKEN etc -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Resolved: (JGRP-182) Externalize thread creation

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-182?page=all ] Bela Ban resolved JGRP-182. --------------------------- Resolution: Duplicate Issue Duplicate of central thread pool > Externalize thread creation > --------------------------- > > Key: JGRP-182 > URL: http://jira.jboss.com/jira/browse/JGRP-182 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9.1, 2.2.9, 2.2.8, 2.3 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.5 > > > Provide a (factory-based) way for devs to plug in their own thread pool implementations (probably based on util.concurrent's Executor). > This externalizes the creation of threads, so devs can for example place threads in their own thread groups. > There will be a default implementation -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-303) Verify that all synchronized statements have short scopes

by Bela Ban (JIRA)

Verify that all synchronized statements have short scopes --------------------------------------------------------- Key: JGRP-303 URL: http://jira.jboss.com/jira/browse/JGRP-303 Project: JGroups Issue Type: Task Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 In all cases when we have a passUp() or passDown() call from within a synchronized statement, we need to verify whether (a) we can call passDown()/passUp() outside the synchronized statement or (b) whether there is a potential deadlock if we don't -- 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

19 years, 3 months

1
2
0 / 0

[JBoss JIRA] Closed: (JBPM-608) add support for descriptions on most elements

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-608?page=all ] Koen Aers closed JBPM-608. -------------------------- Resolution: Done replaced by GPD-30 > add support for descriptions on most elements > --------------------------------------------- > > Key: JBPM-608 > URL: http://jira.jboss.com/jira/browse/JBPM-608 > Project: JBoss jBPM > Issue Type: Sub-task > Components: Graphical Process Designer > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-400) Concurrent stack: implement Wait RejectionPolicy

by Bela Ban (JIRA)

Concurrent stack: implement Wait RejectionPolicy ------------------------------------------------ Key: JGRP-400 URL: http://jira.jboss.com/jira/browse/JGRP-400 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBPM-587) GPD crashes if xmlbuddy plugin is installed

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-587?page=all ] Koen Aers closed JBPM-587. -------------------------- Resolution: Done Assignee: Koen Aers (was: Tom Baeyens) I suppose this issue has been resolved by the more recent releases of JBoss IDE. > GPD crashes if xmlbuddy plugin is installed > ------------------------------------------- > > Key: JBPM-587 > URL: http://jira.jboss.com/jira/browse/JBPM-587 > Project: JBoss jBPM > Issue Type: Bug > Components: Graphical Process Designer > Affects Versions: jBPM GPD 3.0.8 > Environment: Gentoo Linux / Eclipse 3.1.2 > Reporter: Matthias Germann > Assigned To: Koen Aers > > If the Graphical Process Designer plugin and the XML Buddy Plugin are installed in the same eclipse installation, the GPD crases when opening a process definition file. The problem can be reproduced by unzipping the XML Buddy Free Edition ZIP File into the plugins directory of a eclipse installation with GPD installed. > The GPD reports the following error when opening a jBPM process definition File: > Unable to create this part due to an internal error. Reason for the failure: An unexpected exception was thrown. > Detail: > java.lang.NullPointerException > at org.jbpm.ui.editor.DesignerContentProvider.addProcessDiagramDimension(Unknown Source) > at org.jbpm.ui.editor.DesignerContentProvider.addGraphicalInfo(Unknown Source) > at org.jbpm.ui.editor.DesignerContentProvider.addGraphicalInfo(Unknown Source) > at org.jbpm.ui.editor.DesignerContentProvider.addGraphicalInfo(Unknown Source) > at org.jbpm.ui.editor.DesignerGraphicalEditorPage.initInput(Unknown Source) > at org.jbpm.ui.editor.DesignerGraphicalEditorPage.init(Unknown Source) > at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:152) > at org.jbpm.ui.editor.DesignerEditor.addGraphPage(Unknown Source) > at org.jbpm.ui.editor.DesignerEditor.createPages(Unknown Source) > at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:241) > at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:609) > at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:384) > at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:552) > at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:223) > at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2362) > at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2295) > at org.eclipse.ui.internal.WorkbenchPage.access$9(WorkbenchPage.java:2287) > at org.eclipse.ui.internal.WorkbenchPage$9.run(WorkbenchPage.java:2273) > at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) > at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2268) > at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:279) > at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:271) > at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:178) > at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1021) > at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2867) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2572) > at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1699) > at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663) > at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:367) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) > at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:103) > at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163) > 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:585) > at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) > at org.eclipse.core.launcher.Main.basicRun(Main.java:278) > at org.eclipse.core.launcher.Main.run(Main.java:973) > at org.eclipse.core.launcher.Main.main(Main.java:948) -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-378) TLS: check all major protocols for thread safety (reentrant up() methods)

by Bela Ban (JIRA)

TLS: check all major protocols for thread safety (reentrant up() methods) ------------------------------------------------------------------------- Key: JGRP-378 URL: http://jira.jboss.com/jira/browse/JGRP-378 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 So far, the down() methods could get executed in parallel, by different threads calling Channel.send(), However, this was not the case for up(), where we could assume only 1 thread was calling up() at a time. This changed with the threadless stack (TLS) and we need to make sure all of our protocols' up() methods are thread safe -- 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

19 years, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-748) Messaging server can be locke up by broken or malicious clients

by Ovidiu Feodorov (JIRA)

Messaging server can be locke up by broken or malicious clients --------------------------------------------------------------- Key: JBMESSAGING-748 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-748 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.SP2 Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.0.1.SP3 -- 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

19 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 January 2007