August 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1620) location on signoOut method is ignored

by Thomas Heute (JIRA)

location on signoOut method is ignored -------------------------------------- Key: JBPORTAL-1620 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1620 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.1 Final Reporter: Thomas Heute Assigned To: Thomas Heute Fix For: 2.6.2 Final When signing out using the signOut method of JBoss Portlet request, the redirect doesn't happen -- 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, 5 months

1
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-878) correct ejb3 testsuite so that all "expected" failures do not ... well ... fail

by William DeCoste (JIRA)

correct ejb3 testsuite so that all "expected" failures do not ... well ... fail ------------------------------------------------------------------------------- Key: EJBTHREE-878 URL: http://jira.jboss.com/jira/browse/EJBTHREE-878 Project: EJB 3.0 Issue Type: Task Affects Versions: EJB 3.0 RC9 - Patch 1 Reporter: William DeCoste Assigned To: William DeCoste Fix For: EJB 3.0 RC10 - FD -- 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, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-942) support RemoteBindings annotations from ejb3-interceptors-aop.xml

by William DeCoste (JIRA)

support RemoteBindings annotations from ejb3-interceptors-aop.xml ----------------------------------------------------------------- Key: EJBTHREE-942 URL: http://jira.jboss.com/jira/browse/EJBTHREE-942 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.0 CR1, EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD Reporter: William DeCoste Assigned To: William DeCoste The proxy is being created and deployed before the EJBContainer is being started, so the annotations are not populated early enough. See EJBContainer.start() { initializeClassContainer(); } -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-998) enable removal of EJB3 Timers

by William DeCoste (JIRA)

enable removal of EJB3 Timers ----------------------------- Key: EJBTHREE-998 URL: http://jira.jboss.com/jira/browse/EJBTHREE-998 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.0 GA Reporter: William DeCoste Assigned To: William DeCoste -- 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, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1023) setStringProperty call after a clearProperties call will make getJMSDestination to be null

by Clebert Suconic (JIRA)

setStringProperty call after a clearProperties call will make getJMSDestination to be null ------------------------------------------------------------------------------------------ Key: JBMESSAGING-1023 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1023 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.CR1 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.4.0.CR2 -- 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, 5 months

1
2
0 / 0

[JBoss JIRA] Resolved: (GPD-127) CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-127?page=all ] Koen Aers resolved GPD-127. --------------------------- Resolution: Done > CLONE -Page flow is under "JBoss Seam" instead of "Seam" in Wizard dialog > ------------------------------------------------------------------------- > > Key: GPD-127 > URL: http://jira.jboss.com/jira/browse/GPD-127 > Project: JBoss jBPM GPD > Issue Type: Feature Request > Affects Versions: jBPM JPDL Designer 3.1.0.beta2 > Reporter: Koen Aers > Assigned To: Koen Aers > Fix For: jBPM JPDL Designer 3.1.0.CR > > > jbpm should use the same id as "Seam" from jbosstools. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-130) Problems with reincarnation

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12370885 ] Bela Ban commented on JGRP-130: ------------------------------- Implementing GMS.reject_join_from_existing_member pretty much fixed this issue. I don't see the need for logical addresses any more. I added a comment to http://jira.jboss.com/jira/browse/JGRP-129. What do people think, is there still a compelling reason we need logical addresses ? > Problems with reincarnation > --------------------------- > > Key: JGRP-130 > URL: http://jira.jboss.com/jira/browse/JGRP-130 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.6 > > Attachments: tcp.xml > > > Problems with reincarnation > =========================== > Author: Bela Ban > Version: $Id$ > The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless > bind_port is set (not set by default). > Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a > higher port, say 5002. This depends on how many other processes requested a port in between the start and restart > of the member. > JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically) > *increasing* across a single machine. If this is not the case, then the following problems can occur: > 1. Restart: > When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded, > then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table), > retransmission requests sent to the new P will fail. > 2. Shunning: > Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of > those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have > processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time, > when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so > they could assume each other's identity ! > Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a > new process and in case #2, the list is process-wide, but not machine-wide. > Again, these problems occur *only* when the OS reuses previously assigned ports. > SOLUTION: > A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we > don't reuse previous addresses > B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host. > Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity. > The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. -- 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, 5 months

1
0
0 / 0

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

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-129?page=comments#action_12370883 ] Bela Ban commented on JGRP-129: ------------------------------- I'm not sure I want to introduce logical addresses. This is regarding JGRP-129 (logical addresses) and JGRP-130 (problems with reincarnation). JGRP-130 is about a member that leaves and rejoins *under the same IP address and port (using bind/start_port)* before failure detection kicks it out. I implemented a fix for this, which won't allow a member into the group that's already in the group. In the above case, with A and B, B would have to wait until the cluster is {A} before it can rejoin. JGRP-129 is about providing a logical address (possibly host + system time in ms (plus 1 for same system times) for a member, which can be mapped to a physical host/port combo. It would add 4 bytes/address, and I don't see the benefits of this. The original motivation was that when a member gets shunned, it rejoins under a new identity. Sacha didn't like this and therefore added 'logical addresses' in JBoss, which creates a logical address for a member. So when that member is shunned and rejoins under a *new* JGroups address, it would still keep the *old* JBoss logical address. I tend to leave it this way, as I don't want to add something which - adds clutter (Host:26634425614 looks less readable than Host:4536) - adds 4 bytes / IpAddress - has some additional lookup in the transport to find the real physical address to which the logical address maps - needs some ARP-like traffic for establishing local tables which map logical to physical addresses What do people think ? > 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.6 > > > 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, 5 months

1
0
0 / 0

[JBoss JIRA] Resolved: (GPD-126) CLONE -New Page Flow broken - exception

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-126?page=all ] Koen Aers resolved GPD-126. --------------------------- Resolution: Done The problem should be fixed now. > CLONE -New Page Flow broken - exception > --------------------------------------- > > Key: GPD-126 > URL: http://jira.jboss.com/jira/browse/GPD-126 > Project: JBoss jBPM GPD > Issue Type: Bug > Affects Versions: jBPM JPDL Designer 3.1.0.beta2 > Reporter: Koen Aers > Assigned To: Koen Aers > Priority: Blocker > Fix For: jBPM JPDL Designer 3.1.0.CR > > > Ctrl+N, select Page Flow and Next or Finish gives multiple errors and the dialog is just stuck: > java.lang.IllegalArgumentException: Path must include project and resource name: / > at org.eclipse.core.runtime.Assert.isLegal(Assert.java:62) > at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1625) > at org.eclipse.core.internal.resources.Container.getFolder(Container.java:137) > at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getProcessFolder(Unknown Source) > at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.performFinish(Unknown Source) > at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:742 > java.lang.NullPointerException > at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.getRootForEmbeddingProject(Unknown Source) > at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.initContainerName(Unknown Source) > at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.init(Unknown Source) > at org.jbpm.ui.pageflow.wizard.NewPageFlowWizard.addPages(Unknown Source) > at org.eclipse.jface.wizard.WizardSelectionPage.getNextPage(WizardSelectionPage.java:113) > java.lang.IllegalArgumentException: Argument cannot be null > at org.eclipse.swt.SWT.error(SWT.java:3547) > at org.eclipse.swt.SWT.error(SWT.java:3481) > at org.eclipse.swt.SWT.error(SWT.java:3452) > at org.eclipse.swt.widgets.Widget.error(Widget.java:438) > at org.eclipse.swt.widgets.Text.setText(Text.java:1870) > at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createContainerField(Unknown Source) > at org.jbpm.ui.pageflow.wizard.NewPageFlowWizardPage.createControl(Unknown Source) > at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170) > at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:669) > at org.eclipse.jface.wizard.WizardDialog.setWizard(WizardDialog.java:1083) > at org.eclipse.jface.wizard.WizardDialog.updateForPage(WizardDialog.java:1142) -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1023) Default local interface is not picked up if class is woven with JBoss AOP

by Kabir Khan (JIRA)

Default local interface is not picked up if class is woven with JBoss AOP ------------------------------------------------------------------------- Key: EJBTHREE-1023 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1023 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.1.GA, EJB 3.0 RC9 - Patch 1 Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD If weaving the following bean public interface SessionLocal{ void method(); } @Stateful public bean Session implements Session{ void method(){} } following weaving it implements Session AND org.jboss.aop.Advised, i.e. > 1 interface so the local proxy does not get bound into JNDI. -- 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, 5 months

1
1
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 August 2007