October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBESB-15) Basic transformation integration using Smooks

by Tom Fennelly (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-15?page=all ] Tom Fennelly closed JBESB-15. ----------------------------- Resolution: Done > Basic transformation integration using Smooks > --------------------------------------------- > > Key: JBESB-15 > URL: http://jira.jboss.com/jira/browse/JBESB-15 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transformation Service > Affects Versions: 4.0 > Reporter: Mark Little > Assigned To: Tom Fennelly > Priority: Critical > Fix For: 4.0 > > Time Spent: 1 week, 3 days > Remaining Estimate: 0 minutes > > Develop an abstract transformation service interface that does not tie us to any specific implementation. > Look at smooks (http://milyn.org/Smooks) as an initial 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3598) Get the 4.0.5.GA testsuite-1.4 (JRockit) passing

by Dimitris Andreadis (JIRA)

Get the 4.0.5.GA testsuite-1.4 (JRockit) passing ------------------------------------------------ Key: JBAS-3598 URL: http://jira.jboss.com/jira/browse/JBAS-3598 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Dimitris Andreadis Fix For: JBossAS-4.0.5.GA Container task to fix jboss-4.0-testsuite-1.4, run under JRockit -- 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

17 years, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-334) Option to pick random port in TCP/TCP_NIO

by Bela Ban (JIRA)

Option to pick random port in TCP/TCP_NIO ----------------------------------------- Key: JGRP-334 URL: http://jira.jboss.com/jira/browse/JGRP-334 Project: JGroups Issue Type: Feature Request Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 If start_port is omitted or 0, then we let them OS pick an ephemeral (random) port. This helps avoid reincarnation (http://jira.jboss.com/jira/browse/JGRP-130) -- 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

17 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-720) Timeout annotation doesn't work on protected method

by Ilya (JIRA)

Timeout annotation doesn't work on protected method --------------------------------------------------- Key: EJBTHREE-720 URL: http://jira.jboss.com/jira/browse/EJBTHREE-720 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Reporter: Ilya Priority: Minor According to ejb3 spec: ------- ejb-3_0-fr-spec-ejbcore.pdf 18.2 (p. 484) ------------ A Timeout method can have public, private, protected, or package level access. A Timeout method must not be declared as final or static. --------------------------------------------------------------------------- But when I declare timeoutHandler in ExampleTimerBean as protected JBoss throws an exception: 11:39:18,271 ERROR [TimerImpl] Error invoking ejbTimeout: javax.ejb.EJBException: No method has been annotated with @Timeout So, a testcase can be: --------------------------------------------------------------------------- package org.jboss.tutorial.timer.bean; import java.util.Date; import javax.annotation.Resource; import javax.ejb.Remote; import javax.ejb.SessionContext; import javax.ejb.Stateless; import javax.ejb.Timeout; import javax.ejb.Timer; @Stateless @Remote(ExampleTimer.class) public class ExampleTimerBean implements ExampleTimer { private @Resource SessionContext ctx; public void scheduleTimer(long milliseconds) { ctx.getTimerService().createTimer(new Date(new Date().getTime() + milliseconds), "Hello World"); } @Timeout protected void timeoutHandler(Timer timer) { System.out.println("---------------------"); System.out.println("* Received Timer event: " + timer.getInfo()); System.out.println("---------------------"); timer.cancel(); } } --------------------------------------------------------------------------- -- 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

17 years, 6 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_12344417 ] Bela Ban commented on JGRP-130: ------------------------------- Using MPING (for multicast discovery) and setting the TCP.start_port to 0 (so the operating system picks a port) might help avoiding this problem, until logical addresses are available. > 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 > > > 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-376) JSF invalid field "decorators"

by Gavin King (JIRA)

JSF invalid field "decorators" ------------------------------ Key: JBSEAM-376 URL: http://jira.jboss.com/jira/browse/JBSEAM-376 Project: JBoss Seam Issue Type: Feature Request Components: JSF Reporter: Gavin King Assigned To: Gavin King Fix For: 1.1 Tapestry makes it really easy to "decorate" fields with validation failures. JSF does not really (apart from the message). -- 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

17 years, 6 months

1
8
0 / 0

[JBoss JIRA] Created: (JBRULES-507) jbrules docs: minor technical error in RuleBase code example

by Ivelin Ivanov (JIRA)

jbrules docs: minor technical error in RuleBase code example ------------------------------------------------------------ Key: JBRULES-507 URL: http://jira.jboss.com/jira/browse/JBRULES-507 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 3.0.4 Reporter: Ivelin Ivanov Assigned To: Mark Proctor Priority: Minor minor technical error in a code example: http://labs.jboss.com/file-access/default/members/jbossrules/freezone/doc... " At any time Packages can be added and removed - all changes will be propated to the existing Working Memories, don't forget to call fireAllRules() for resulting Activations to fire. ruleBase.addPackage( pkg ); // Add a package instance ruleBase.addPackage( "org.com.sample" ); // remove a package, and all its parts, by it's namespace ruleBase.removeRule( "org.com.sample", "my rule" ); // remove a specific rule from a namespace " the line ruleBase.addPackage( "org.com.sample" ); // remove a package, and all its parts, by it's namespace was probably meant to read ruleBase.removePackage( "org.com.sample" ); // remove a package, and all its parts, by it's namespace -- 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

17 years, 6 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBTM-55) Public WS-A endpoint for testing purposes

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-55?page=all ] Mark Little updated JBTM-55: ---------------------------- Fix Version/s: (was: 4.4) > Public WS-A endpoint for testing purposes > ----------------------------------------- > > Key: JBTM-55 > URL: http://jira.jboss.com/jira/browse/JBTM-55 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Little > Assigned To: Kevin Conner > Priority: Minor > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > Put the W3C-tested WS-A endpoint up for public access. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBTM-92) Print error message when prepare fails in XAResource

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-92?page=all ] Mark Little closed JBTM-92. --------------------------- Resolution: Done > Print error message when prepare fails in XAResource > ---------------------------------------------------- > > Key: JBTM-92 > URL: http://jira.jboss.com/jira/browse/JBTM-92 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA Implementation > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Mark Little > Priority: Minor > Fix For: 4.2.2 > > Time Spent: 10 minutes > Remaining Estimate: 0 minutes > > Currently we fail silently within the XAResourceRecord wrapper and return an error code so the transaction will rollback. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBTM-92) Print error message when prepare fails in XAResource

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-92?page=all ] Mark Little updated JBTM-92: ---------------------------- Fix Version/s: 4.2.2 (was: 4.4) > Print error message when prepare fails in XAResource > ---------------------------------------------------- > > Key: JBTM-92 > URL: http://jira.jboss.com/jira/browse/JBTM-92 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA Implementation > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Mark Little > Priority: Minor > Fix For: 4.2.2 > > > Currently we fail silently within the XAResourceRecord wrapper and return an error code so the transaction will rollback. -- 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

17 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006